На серверах DL380p gen8, использующих XFS поверх LVM поверх raid 1 + 0 с 6 дисками, идентичная рабочая нагрузка приводит к десятикратному увеличению количества операций записи на диск в RHEL 6 по сравнению с RHEL 5, что делает приложения непригодными для использования.
Обратите внимание, что я не стремлюсь максимально оптимизировать систему co6, а хочу понять, почему co6 ведет себя так сильно по-другому, и решить эту проблему.
У нас есть репликация 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 в 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 на rhel 6, говорят, что отключение огромных страниц и особенно прозрачных огромных страниц может быть полезным. Оба отключили, проблема никуда не делась.
Мы уже много пробовали и наблюдали, но ни одно из следующего не помогло:
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 - это норма. По умолчанию полоса размер 256 КБ должен подойти для этого приложения.
Я бы потенциально попробовал это без LVM.
Какие твои sysctl.conf параметры?
У нас была аналогичная проблема, и мы выяснили, что это связано с изменением версии журнала XFS. Журналы версии 2 учитывают установленную ширину полосы, используемую с mkfs.xfs. Если вы часто выполняете fsync, ваша рейд-карта больше не сможет подделывать записи этих журналов. Вы можете протестировать это, отформатировав раздел без какой-либо настройки ширины (это не имеет значения для RAID 1 + 0). Вы можете проверить это с помощью blktrace / seekwatcher, чтобы увидеть, требует ли он большого количества обновлений журнала.