На серверах gen8 DL380p, що використовують XFS поверх LVM поверх рейду 1 + 0 з 6 дисками, однакове робоче навантаження призводить до десятикратного збільшення запису диска на RHEL 6 порівняно з RHEL 5, що робить додатки непридатними.

Зауважте, що я не дивлюся на оптимізацію системи co6 якнайбільше, а на розуміння того, чому co6 поводиться так дико по-різному, і вирішуючи це.

vmstat / іостат

Ми маємо налаштування реплікації MySQL, використовуючи mysql 5.5. Mysql-раби на серверах gen8, що використовують RHEL 6 як ОС, погано спрацьовують, перевірка за допомогою vmstat та iostat показує, що ці сервери роблять в десять разів більше активності сторінки та вдесятеро перевищують кількість записів на дискову підсистему. blktrace показують, що ці записи ініціюються не mysql, а ядром.

Centos 5:

[dkaarsemaker@co5 ~]$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0     12 252668 102684 10816864    0    0     8   124    0    0  9  1 90  0  0
 1  0     12 251580 102692 10817116    0    0    48  2495 3619 5268  6  1 93  0  0
 3  0     12 252168 102692 10817848    0    0    32  2103 4323 5956  6  1 94  0  0
 3  0     12 252260 102700 10818672    0    0   128  5212 5365 8142 10  1 89  0  0

[dkaarsemaker@co5 ~]$ iostat 1
Linux 2.6.18-308.el5 (bc290bprdb-01.lhr4.prod.booking.com)  02/28/2013

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.74    0.00    0.81    0.25    0.00   90.21

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      277.76       399.60      5952.53 2890574849 43058478233
cciss/c0d0p1      0.01         0.25         0.01    1802147      61862
cciss/c0d0p2      0.00         0.01         0.00     101334      32552
cciss/c0d0p3    277.75       399.34      5952.52 2888669185 43058383819
dm-0             32.50        15.00       256.41  108511602 1854809120
dm-1            270.24       322.97      5693.34 2336270565 41183532042

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.49    0.00    0.79    0.08    0.00   91.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      300.00        32.00      4026.00         32       4026
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    300.00        32.00      4026.00         32       4026
dm-0              0.00         0.00         0.00          0          0
dm-1            300.00        32.00      4026.00         32       4026

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.25    0.00    0.46    0.21    0.00   95.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      507.00       160.00     10370.00        160      10370
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    507.00       160.00     10370.00        160      10370
dm-0              0.00         0.00         0.00          0          0
dm-1            507.00       160.00     10370.00        160      10370

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.33    0.00    0.50    0.08    0.00   94.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0      318.00        64.00      4559.00         64       4559
cciss/c0d0p1      0.00         0.00         0.00          0          0
cciss/c0d0p2      0.00         0.00         0.00          0          0
cciss/c0d0p3    319.00        64.00      4561.00         64       4561
dm-0              0.00         0.00         0.00          0          0
dm-1            319.00        64.00      4561.00         64       4561

А на Centos 6 десятикратне збільшення підкачки і диск пише:

[root@co6 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 361044  52340 81965728    0    0    19  1804   36  110  1  1 98  0  0  
 0  0      0 358996  52340 81965808    0    0   272 57584 1211 3619  0  0 99  0  0  
 2  0      0 356176  52348 81966800    0    0   240 34128 2121 14017  1  0 98  0  0 
 0  1      0 351844  52364 81968848    0    0  1616 29128 3648 3985  1  1 97  1  0  
 0  0      0 353000  52364 81969296    0    0   480 44872 1441 3480  1  0 99  0  0  

[root@co6 ~]# iostat 1
Linux 2.6.32-279.22.1.el6.x86_64 (bc291bprdb-01.lhr4.prod.booking.com)  02/28/2013  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.08    0.00    0.67    0.27    0.00   97.98

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             373.48      1203.02    115203.05   11343270 1086250748
dm-0             63.63        74.92       493.63     706418    4654464
dm-1            356.48      1126.72    114709.47   10623848 1081596740

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.19    0.06    0.00   99.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             330.00        80.00     77976.00         80      77976
dm-0              0.00         0.00         0.00          0          0
dm-1            328.00        64.00     77456.00         64      77456

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.38    0.00    0.19    0.63    0.00   98.81

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             570.00      1664.00    128120.00       1664     128120
dm-0              0.00         0.00         0.00          0          0
dm-1            570.00      1664.00    128120.00       1664     128120

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.66    0.00    0.47    0.03    0.00   98.84

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             317.00       448.00     73048.00        448      73048
dm-0             34.00         0.00       272.00          0        272
dm-1            309.00       448.00     72776.00        448      72776

Звуження вниз

Сервери Gen 8, що використовують RHEL 5, і сервери gen 7, що використовують RHEL 5 або 6, не виявляють цієї проблеми. Крім того, RHEL 6 з ext3 як файловою системою замість наших xfs за замовчуванням не виявляє проблеми. Здається, проблема справді є десь між обладнанням XFS, gen8 та centos 6. RHEL 6 також показує проблему.

Редагувати 29/04: ми додали qlogic HBA до машини G8. Використання XFS для зберігання волоконних каналів не виявляє проблеми. Тож це безумовно десь у взаємодії між xfs / hpsa / p420i.

XFS

Новіші xfs у rhel 8, здається, зможуть виявити основу ширини смуги, але лише на контролерах p420i, що використовують драйвер hpsa, а не на контролерах p410i, що використовують cciss.

xfs_info вихід:

[root@co6 ~]# xfs_info /mysql/bp/
meta-data=/dev/mapper/sysvm-mysqlVol isize=256    agcount=16, agsize=4915136 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642176, imaxpct=25
         =                       sunit=64     swidth=192 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

sunit / swidth є обома 0 у всіх налаштуваннях, позначених як OK вище. Ми, здається, не можемо змінити це ні в mkfs, ні з опцією кріплення noalign. Ми також не знаємо, чи це причина.

Величезні сторінки

Інші люди, що мають проблеми з XFS на 6-й рік, кажуть, що вимкнення величезних сторінок і особливо прозорих величезних сторінок може бути корисним. Ми відключили обох, проблема не згасла.

Ми вже спробували і спостерігали багато речей, жодне з наступного не допомогло:

• Використання numactl для впливу на розподіл пам'яті. Ми помітили, що g7 та g8 мають різну структуру numa, ефекту не було помічено
• Новіші ядра (як нові 3.6), схоже, не вирішили цього. Ніхто не використовував Fedora 17.
• iostat не повідомляє про десятикратне збільшення трансакцій запису, лише у кількості записаних байтів
• Використання різних планувальників вводу-виводу не впливає.
• Встановлення відповідної файлової системи noatime / nobarrier / nopdiratime не допомогло
• Зміна / proc / sys / vm / dirty_ratio не мала ефекту
• Це відбувається як на системах на базі 2640, так і 2670 процесорів
• hpsa-3.2.0 не вирішує проблему

XFS і EL6 впали в некрасивий стан ... Я поки що відмовився від XFS в системах EL6 через кілька функцій / змін, що протікають в ядрі Red Hat ...

Це стало несподіванкою і викликало деяку паніку: Чому мої файлові системи XFS раптом витрачають більше місця та наповнені розрідженими файлами?

Починаючи з листопада 2012 року, версія XFS в ядрах новіших, ніж 2.6.32-279.11.1.el6дратує навантаження та продуктивність, що випливає з Red Hat Bugzilla 860787 . З тих пір у мене були непередбачувані показники продуктивності та вищі черги на виконання, ніж у середньому.

Для нових систем я використовую ZFS або просто ext4. Для старих систем я заморожую їх 2.6.32-279.11.1.el6.

Спробуйте повернутися до цієї версії за допомогою:

yum install kernel-2.6.32-279.11.1.el6.x86_64

На додаток до вищезазначеного, через тип RAID-контролера, який ви використовуєте, типові оптимізації в порядку:

Змонтуйте файлові системи XFS noatime. Ви також повинні використовувати налаштовану рамку за допомогою:

tuned-adm profile enterprise-storage

встановити ліфти для читання, нобар'єр та ліфт для вводу / виводу на хорошу базову лінію.

Редагувати:

Існує маса рекомендацій щодо оптимізації файлової системи XFS. Я використовував файлову систему виключно протягом останнього десятиліття, і мені доводилося періодично коригувати параметри, оскільки відбулися основні зміни в операційній системі. Я не відчував такого різкого зниження продуктивності, як ваше, але також не використовую LVM.

Я думаю, що нерозумно очікувати, що EL5 діятиме так само, як і EL6 , враховуючи різну генерацію ядра, компільовані за замовчуванням, планувальники, пакети тощо.

Що б я зробив у цей момент ??

• Я вивчив би параметри mkfs.xfs і як ви будуєте системи. Чи використовуєте ви розділення XFS під час встановлення чи створення розділів після факту? Я створюю файлову систему XFS після основної установки ОС, оскільки маю більшу гнучкість у заданих параметрах.

• Мої параметри створення mkfs.xfs прості: mkfs.xfs -f -d agcount=32 -l size=128m,version=2 /dev/sdb1наприклад.

• Мої варіанти кріплення: noatime,logbufs=8,logbsize=256k,nobarrierЯ дозволяю динамічній попередній локалізації XFS запускатись на самому місці і не обмежувати її, як у вас тут. Моя продуктивність покращилася.

• Тому я не використовую LVM . Особливо поверх апаратних RAID ... Особливо на контролерах HP Smart Array, де є деякі функції, подібні до LVM, притаманних пристрою. Однак, використовуючи LVM, ви не маєте доступу до fdiskстворення необроблених розділів. Одне, що змінилося з EL5 на EL6 - це вирівнювання розділів у програмі встановлення та зміна на fdisk для встановлення пускового сектора на межі циліндра.

• Переконайтеся, що ви використовуєте контролери та накопичувачі HP Smart Array на поточному рівні версії. У цей момент є сенс оновити весь сервер до поточного пакета оновлень HP для перегляду програмного забезпечення ProLiant . Це завантажувальний DVD, який буде оновити всі виявлені компоненти в системі.

• Я перевірив би настройки RAID-контролера. Вставте вихід hpacucli ctrl all show config detail. Ось моя. Ви хочете, щоб відношення кешу було упередженим щодо запису проти прочитаного. 75:25 - це норма. Розмір смужки за замовчуванням 256K повинен бути чудовим для цієї програми.

• Я б потенційно спробував це без LVM.

• Які ваші sysctl.confпараметри?

У нас була подібна проблема, і ми з’ясували, що це пов'язано зі зміною версії журналу XFS. Журнали версії 2 вшановують набір ширини смуги, який використовується з mkfs.xfs. Якщо ви робите багато fsync, ваша рейдова картка більше не може підробляти ці записи в журналах. Ви можете протестувати його, відформатувавши розділ без будь-яких параметрів ширини (це не має різниці з RAID 1 + 0). Ви можете переконатись у тому, що програма blktrace / searchwatcher перевіряє, чи передбачає вона багато оновлення журналу.