Журнал LinuxFormat - перейти на главную

КТО УНАСЛЕДУЕТ БИЗНЕС-ИМПЕРИЮ ПРИГОЖИНА

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «Категория: Главное в Linux ==Об­нов­ляй­тесь!== ''Ко­ман­да LXF це­лый ме­сяц тес­ти­ро­ва…»)
 
 
(не показаны 16 промежуточных версий 2 участников)
Строка 1: Строка 1:
 
[[Категория: Главное в Linux]]   
 
[[Категория: Главное в Linux]]   
==Об­нов­ляй­тесь!==
+
{{SEO}}
  
''Ко­ман­да LXF це­лый ме­сяц тес­ти­ро­ва­ла ма­те­рин­ские пла­ты, про­цес­со­ры, твер­до­тель­ные дис­ки и ви­део­кар­ты,  
+
Есть и дру­гие на­строй­ки, спо­соб­ные уве­ли­чить срок служ­бы дис­ка.
что­бы убе­речь вас от это­го.''
+
  
Когда вы раз­мыш­ляе­те, что никто из нас так не при­ки­пел бы к Linux, ес­ли бы не «же­ле­зо», на ко­то­ром он ра­бо­та­ет, вы уде­ляе­те ма­ло внимания плат­фор­ме x86. Воз­мож­но, де­ло в том, что Linux стал весь­ма ста­би­лен и от­лич­но ра­бо­та­ет на бо­лее ста­рых уст­рой­ст­вах, и нам ред­ко при­хо­дит­ся об этом ду­мать.
+
Про­стей­шая из них – до­ба­вить к оп­ци­ям мон­ти­ро­вания noatime, точ­но так же, как ранее мы до­ба­ви­ли оп­цию discard. В фай­ло­вых сис­те­мах Linux обыч­но хра­нят­ся вре­мя по­следнего чтения и по­следнего из­менения фай­ла. С оп­ци­ей noatime бу­дет со­хра­нять­ся толь­ко вре­мя по­следнего из­менения, что снизит чис­ло опе­ра­ций за­пи­си и уве­ли­чит срок служ­бы дис­ка. Од­на­ко пре­ду­пре­ж­да­ем: ста­рые про­грам­мы, вро­де Mutt, не бу­дут ра­бо­тать пра­виль­но с этой оп­ци­ей, по­это­му сна­ча­ла про­верь­те со­вмес­ти­мость при­ло­жений.
  
Но есть, од­на­ко, и дру­гая при­чи­на. И это со­вмес­ти­мость и про­из­во­ди­тель­ность. Хо­тя со­вмес­ти­мость уже не яв­ля­ет­ся та­кой про­бле­мой, как бы­ло 10 лет, никто из нас не за­хо­чет ра­зо­рить­ся на «же­ле­зо» с со­мнитель­ной под­держ­кой Linux, будь то све­жий чип­сет от Intel, ви­део­кар­та или твер­до­тель­ный же­ст­кий диск. По­это­му мы взя­ли столь­ко ком­понен­тов, сколь­ко смог­ли, и про­тес­ти­ро­ва­ли их на со­вмес­ти­мость и про­из­во­ди­тель­ность.
+
Срок служ­бы дис­ка мож­но так­же уве­ли­чить, тща­тель­но про­ду­мав, ка­кие раз­де­лы на нем раз­мес­тить. На­при­мер, ес­ли на­ря­ду с SSD в сис­те­ме есть обыч­ный же­ст­кий диск, сто­ит раз­мес­тить на SSD фай­ло­вые сис­те­мы, доступ к ко­то­рым осу­ще­ст­в­ля­ет­ся ре­же, та­кие как / и /home, а /var, /tmp и swap раз­мес­тить на обыч­ном дис­ке. Ес­ли та­кой ва­ри­ант вам не под­хо­дит, мож­но на­стро­ить и дру­гие па­ра­мет­ры, ра­ди снижения час­то­ты за­пи­си в эти ка­та­ло­ги. На­при­мер, мож­но уве­ли­чить уро­вень серь­ез­но­сти за­пи­сы­вае­мых в лог со­об­щений, из­менив файл /etc/rsyslog.conf (под­роб­но­сти см. че­рез man rsyslog.conf), или умень­шить «ак­тив­ность под­кач­ки» сис­те­мы, что­бы она как можно ре­же поль­зо­ва­лась фай­лом под­кач­ки. Для это­го вы­полните следующую ко­ман­ду:
  
Что­бы сде­лать наш об­зор бо­лее прак­тич­ным, мы ре­ши­ли не ка­сать­ся пе­реднего края тех­но­ло­гий про­цес­со­ров и ви­део­карт. И не толь­ко что­бы дать Linux пе­ре­дыш­ку на ох­ват этих уст­ройств, но и по­то­му, что со вре­менем це­ны на них ста­нут бо­лее ра­зум­ны­ми. Мы так­же ста­ра­лись рас­ска­зать о кон­ку­ри­рую­щих про­дук­тах, на­при­мер, ви­део­кар­тах AMD и Nvidia и про­цес­со­рах Intel и AMD, в на­де­ж­де по­лу­чить бо­лее раз­но­сто­ронний об­зор то­го, что ра­бо­та­ет хо­ро­шо, а что мо­жет не ра­бо­тать. Мы про­тес­ти­ро­ва­ли разницу в про­из­во­ди­тель­но­сти ме­ж­ду 32-бит­ны­ми и 64-бит­ны­ми плат­фор­ма­ми, про­ана­ли­зи­ро­ва­ли улуч­шения фай­ло­вой сис­те­мы, а имен­но кэш на осно­ве твер­до­тель­но­го же­ст­ко­го дис­ка, и про­ве­ри­ли, на­сколь­ко хо­ро­ши от­кры­тые драй­ве­ры ви­део­карт. И хо­тя мы не да­ем кон­крет­ных ре­ко­мен­да­ций по по­во­ду по­куп­ки тех или иных уст­ройств, мы чет­ко го­во­рим, что ра­бо­та­ет, а что нет.
+
echo 1 > /proc/sys/vm/swappiness
[[Файл:LXF161.feat_hardware.mo_opt.png |left |400px ||]]
+
 
[[Файл:301495.png |left |400px |]]
+
====На­ши тес­то­вые дис­ки====
 +
 
 +
Боль­шин­ст­во SSD ис­поль­зу­ют при­мер­но оди­на­ко­вую тех­но­ло­гию хранения дан­ных. На про­из­во­ди­тель­ность боль­ше влия­ют кон­трол­лер и про­шив­ка уст­рой­ст­во ре­ша­ет, когда и ку­да за­пи­сать дан­ные. Пло­хой кон­трол­лер мо­жет за­мед­лить диск, осо­бен­но со вре­менем, и при­вес­ти к из­менению про­из­во­ди­тель­но­сти при опе­ра­ци­ях за­пи­си раз­но­го раз­ме­ра (на­при­мер, и 9К).
 +
 
 +
Два на­ших тес­то­вых дис­ка про­де­мон­ст­ри­ро­ва­ли два кон­ку­ри­рую­щих кон­трол­ле­ра. В Crucial M4 ис­поль­зу­ет­ся кон­трол­лер Marvell, а в Intel 330 – Sandforce. Эти же кон­трол­ле­ры ис­поль­зу­ют­ся и на мно­же­ст­ве дру­гих дис­ков, так что на­ши ре­зуль­та­ты по­мо­гут вам вы­брать диск для по­куп­ки, да­же ес­ли он бу­дет дру­гим.
 +
 
 +
Мы про­тес­ти­ро­ва­ли дис­ки с по­мо­щью тес­тов Postmark, Compile Bench и Kernel Unpacking из на­бо­ра тес­тов Phoronix Test Suite, что­бы рас­смот­реть их про­из­во­ди­тель­ность в ре­аль­ных си­туа­ци­ях. Все тес­ты про­во­ди­лись в Ubuntu 12.04 с фай­ло­вой сис­те­мой ext4 и оп­ци­ей discard в /etc/fstab.
 +
 
 +
По­жа­луй, ин­те­реснее всех тест Compile Bench, так как он пы­та­ет­ся ими­ти­ро­вать опе­ра­ции, ко­то­рые ста­рят фай­ло­вую сис­те­му – са­мый вер­ный сце­на­рий для на­груз­ки кон­трол­ле­ра. На этих тес­тах диск Intel с кон­трол­ле­ром Sandforce по­ка­зал го­раз­до луч­шие ре­зуль­та­ты.
 +
 
 +
Од­на­ко диск Crucial был го­раз­до бы­ст­рее при ра­бо­те со мно­же­ст­вом ма­лень­ких фай­лов в тес­те PostMark и немно­го бы­ст­рее при рас­па­ков­ке яд­ра.
 +
 
 +
Оба дис­ка сто­ят оди­на­ко­во; че­рез Ин­тернет их мож­но ку­пить от £84 и вы­ше. |
 +
 
 +
«Дис­ков та­ко­го же объ­е­ма, как тра­ди­ци­он­ные, ку­пить нель­зя.»
 +
 
 +
====На­строй­ки про­из­во­ди­тель­но­сти====
 +
 
 +
Для тех, кто по­ме­шан на ско­ро­сти, есть па­ра на­стро­ек, ко­то­рые мож­но при­менить для уве­ли­чения ско­ро­сти дис­ка. Од­на из них вклю­ча­ет пра­виль­ное вы­равнивание раз­де­лов, но о ней уже рас­ска­зал Нейл Бот­вик в LXF160, и здесь мы не бу­дем уг­луб­лять­ся в де­та­ли.
 +
 
 +
Дру­гая – из­менить на­строй­ки планиров­щи­ка дис­ка. Он оп­ре­де­ля­ет по­ря­док вы­де­ления бло­ков дис­ка: на вра­щаю­щих­ся же­ст­ких дис­ках планиров­щик ис­поль­зо­вал­ся для на­зна­чения при­ори­те­тов одним бло­кам дис­ка по от­но­шению к дру­гим (вре­мя досту­па к бло­ку раз­ли­ча­ет­ся по ме­ре его бли­зо­сти к цен­тру дис­ка). А в SSD вре­ме­на досту­па к бло­кам поч­ти оди­на­ко­вы, и та­кая дис­кри­ми­на­ция мо­жет зна­чи­тель­но снизить про­из­во­ди­тель­ность, по­это­му сто­ит пе­ре­клю­чить­ся на «хо­ло­стой [noop]» планиров­щик:
 +
 
 +
echo noop > /sys/block/<ssd>/queue/scheduler.
 +
 
 +
{| class="standart"
 +
|+ '''Результаты: ''' 
 +
| [[Файл: 304682.png| center |thumb|300px|Postmark, Compile Bench Initial Create, Compile Bench Compile, Compile Bench, Read Compiled Tree, Unpacking the Linux Kernel ]]
 +
| [[Файл: 305098.png| center |thumb|300px|Postmark, Compile Bench Initial Create, Compile Bench Compile, Compile Bench, Read Compiled Tree, Unpacking the Linux Kernel ]]
 +
|}

Текущая версия на 07:13, 13 октября 2023

Есть и дру­гие на­строй­ки, спо­соб­ные уве­ли­чить срок служ­бы дис­ка.

Про­стей­шая из них – до­ба­вить к оп­ци­ям мон­ти­ро­вания noatime, точ­но так же, как ранее мы до­ба­ви­ли оп­цию discard. В фай­ло­вых сис­те­мах Linux обыч­но хра­нят­ся вре­мя по­следнего чтения и по­следнего из­менения фай­ла. С оп­ци­ей noatime бу­дет со­хра­нять­ся толь­ко вре­мя по­следнего из­менения, что снизит чис­ло опе­ра­ций за­пи­си и уве­ли­чит срок служ­бы дис­ка. Од­на­ко пре­ду­пре­ж­да­ем: ста­рые про­грам­мы, вро­де Mutt, не бу­дут ра­бо­тать пра­виль­но с этой оп­ци­ей, по­это­му сна­ча­ла про­верь­те со­вмес­ти­мость при­ло­жений.

Срок служ­бы дис­ка мож­но так­же уве­ли­чить, тща­тель­но про­ду­мав, ка­кие раз­де­лы на нем раз­мес­тить. На­при­мер, ес­ли на­ря­ду с SSD в сис­те­ме есть обыч­ный же­ст­кий диск, сто­ит раз­мес­тить на SSD фай­ло­вые сис­те­мы, доступ к ко­то­рым осу­ще­ст­в­ля­ет­ся ре­же, та­кие как / и /home, а /var, /tmp и swap раз­мес­тить на обыч­ном дис­ке. Ес­ли та­кой ва­ри­ант вам не под­хо­дит, мож­но на­стро­ить и дру­гие па­ра­мет­ры, ра­ди снижения час­то­ты за­пи­си в эти ка­та­ло­ги. На­при­мер, мож­но уве­ли­чить уро­вень серь­ез­но­сти за­пи­сы­вае­мых в лог со­об­щений, из­менив файл /etc/rsyslog.conf (под­роб­но­сти см. че­рез man rsyslog.conf), или умень­шить «ак­тив­ность под­кач­ки» сис­те­мы, что­бы она как можно ре­же поль­зо­ва­лась фай­лом под­кач­ки. Для это­го вы­полните следующую ко­ман­ду:

echo 1 > /proc/sys/vm/swappiness

[править] На­ши тес­то­вые дис­ки

Боль­шин­ст­во SSD ис­поль­зу­ют при­мер­но оди­на­ко­вую тех­но­ло­гию хранения дан­ных. На про­из­во­ди­тель­ность боль­ше влия­ют кон­трол­лер и про­шив­ка – уст­рой­ст­во ре­ша­ет, когда и ку­да за­пи­сать дан­ные. Пло­хой кон­трол­лер мо­жет за­мед­лить диск, осо­бен­но со вре­менем, и при­вес­ти к из­менению про­из­во­ди­тель­но­сти при опе­ра­ци­ях за­пи­си раз­но­го раз­ме­ра (на­при­мер, 4К и 9К).

Два на­ших тес­то­вых дис­ка про­де­мон­ст­ри­ро­ва­ли два кон­ку­ри­рую­щих кон­трол­ле­ра. В Crucial M4 ис­поль­зу­ет­ся кон­трол­лер Marvell, а в Intel 330 – Sandforce. Эти же кон­трол­ле­ры ис­поль­зу­ют­ся и на мно­же­ст­ве дру­гих дис­ков, так что на­ши ре­зуль­та­ты по­мо­гут вам вы­брать диск для по­куп­ки, да­же ес­ли он бу­дет дру­гим.

Мы про­тес­ти­ро­ва­ли дис­ки с по­мо­щью тес­тов Postmark, Compile Bench и Kernel Unpacking из на­бо­ра тес­тов Phoronix Test Suite, что­бы рас­смот­реть их про­из­во­ди­тель­ность в ре­аль­ных си­туа­ци­ях. Все тес­ты про­во­ди­лись в Ubuntu 12.04 с фай­ло­вой сис­те­мой ext4 и оп­ци­ей discard в /etc/fstab.

По­жа­луй, ин­те­реснее всех тест Compile Bench, так как он пы­та­ет­ся ими­ти­ро­вать опе­ра­ции, ко­то­рые ста­рят фай­ло­вую сис­те­му – са­мый вер­ный сце­на­рий для на­груз­ки кон­трол­ле­ра. На этих тес­тах диск Intel с кон­трол­ле­ром Sandforce по­ка­зал го­раз­до луч­шие ре­зуль­та­ты.

Од­на­ко диск Crucial был го­раз­до бы­ст­рее при ра­бо­те со мно­же­ст­вом ма­лень­ких фай­лов в тес­те PostMark и немно­го бы­ст­рее при рас­па­ков­ке яд­ра.

Оба дис­ка сто­ят оди­на­ко­во; че­рез Ин­тернет их мож­но ку­пить от £84 и вы­ше. |

«Дис­ков та­ко­го же объ­е­ма, как тра­ди­ци­он­ные, ку­пить нель­зя.»

[править] На­строй­ки про­из­во­ди­тель­но­сти

Для тех, кто по­ме­шан на ско­ро­сти, есть па­ра на­стро­ек, ко­то­рые мож­но при­менить для уве­ли­чения ско­ро­сти дис­ка. Од­на из них вклю­ча­ет пра­виль­ное вы­равнивание раз­де­лов, но о ней уже рас­ска­зал Нейл Бот­вик в LXF160, и здесь мы не бу­дем уг­луб­лять­ся в де­та­ли.

Дру­гая – из­менить на­строй­ки планиров­щи­ка дис­ка. Он оп­ре­де­ля­ет по­ря­док вы­де­ления бло­ков дис­ка: на вра­щаю­щих­ся же­ст­ких дис­ках планиров­щик ис­поль­зо­вал­ся для на­зна­чения при­ори­те­тов одним бло­кам дис­ка по от­но­шению к дру­гим (вре­мя досту­па к бло­ку раз­ли­ча­ет­ся по ме­ре его бли­зо­сти к цен­тру дис­ка). А в SSD вре­ме­на досту­па к бло­кам поч­ти оди­на­ко­вы, и та­кая дис­кри­ми­на­ция мо­жет зна­чи­тель­но снизить про­из­во­ди­тель­ность, по­это­му сто­ит пе­ре­клю­чить­ся на «хо­ло­стой [noop]» планиров­щик:

echo noop > /sys/block/<ssd>/queue/scheduler.

Результаты:
(thumbnail)
Postmark, Compile Bench Initial Create, Compile Bench Compile, Compile Bench, Read Compiled Tree, Unpacking the Linux Kernel
(thumbnail)
Postmark, Compile Bench Initial Create, Compile Bench Compile, Compile Bench, Read Compiled Tree, Unpacking the Linux Kernel
Персональные инструменты
купить
подписаться
Яндекс.Метрика