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

Обратите внимание, что я смотрю не столько на оптимизацию системы co6, сколько на понимание, а на понимание того, почему co6 ведет себя так дико, и на решение этой проблемы.

vmstat / IOSTAT

У нас есть настройка репликации 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

Сужается

Серверы поколения 8, использующие RHEL 5, и серверы поколения 7, использующие RHEL 5 или 6, не показывают эту проблему. Кроме того, RHEL 6 с файловой системой ext3 вместо нашей стандартной xfs не показывает проблему. Кажется, проблема действительно где-то между XFS, аппаратным обеспечением gen8 и centos 6. RHEL 6 также показывает проблему.

Редактировать 29/04: мы добавили qlogic HBA на машину G8. Использование XFS в хранилище Fibre Channel не показывает проблему. Так что это определенно где-то во взаимодействии между 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 во всех настройках, помеченных как ОК выше. Кажется, мы не можем изменить это ни в mkfs, ни с помощью опции монтирования noalign. Мы также не знаем, является ли это причиной.

Hugepages

Другие люди, имеющие проблемы с XFS на шестом этапе, говорят, что отключение огромных страниц, и особенно прозрачных огромных страниц, может быть полезным. Мы оба отключили, проблема не исчезла.

Мы уже попробовали и наблюдали много вещей, ни одно из следующего не помогло:

• Использование 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 Framework с:

tuned-adm profile enterprise-storage

установить readahead, nobarrier и I / O Lift на хороший базовый уровень.

Редактировать:

Существует множество рекомендаций по оптимизации файловой системы 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 Service Pack для ProLiant . Это загрузочный DVD, который обновит все обнаруженные компоненты в системе.

• Я бы проверил настройки контроллера RAID. Pastebin выход hpacucli ctrl all show config detail. Вот мой. Вы хотите, чтобы отношение кеша было смещено в сторону записи по сравнению с чтением. 75:25 это норма. Размер полосы по умолчанию 256K должен подойти для этого приложения.

• Я бы потенциально попробовал это без LVM.

• Каковы ваши sysctl.confпараметры?

У нас была похожая проблема, и мы выяснили, что это связано с изменением версии журнала XFS. Журналы версии 2 учитывают набор ширины полосы, используемый в mkfs.xfs. Если вы делаете много fsync, ваша рейд карта больше не сможет подделывать записи логов. Вы можете протестировать его, отформатировав раздел без каких-либо настроек ширины (это не имеет никакого значения для RAID 1 + 0). Вы можете проверить это с помощью blktrace / seekwatcher, чтобы убедиться, что в нем много обновлений журнала.