Решено: jbd2 нагружает диски

[Mirror]

На сервере под Debian 6 имеется программный RAID1. И наблюдается картина, подобная описанной в этой теме: http://forum.ubuntu.ru/index.php?topic=157348.0 То есть, через небольшие промежутки времени процесс jbd2/md2-8 занимает весь дисковый ввод-вывод. Проверка осуществляется с помощью iotop.

Также процесс md2_raid1 все время показывает 99% нагрузки на IO, хотя и нет чтения или записи: iotop показывает, что у него 99%, но чтение и запись = 0. Может быть, это так и нужно - я не очень разбираюсь в технологии.

Также часто поднимается процесс flush-9:2 - я так понимаю, он из этой же серии, он отнимает немало процессора.

Я так понимаю, по ссылке они решили вопрос увеличением времени сброса буферов, но и само решение не слишком безопасное, и для Debian'а оно не подходит.

Как же быть?

Может ли в этом случае помочь переход на аппаратный RAID? Хотелось бы, конечно, найти способ настроить программный, чтобы не терять денег, но если другого выхода нет - будет ли эта потеря оправданной?

[sash-kan]

у вас там тоже ext4?

[sash-kan]

для Debian'а оно не подходит

оно подходит для ext4·
оно — это изменение параметра монтирования "commit"·
переопределение же этого параметра кем-то/чем-то — судя по всему, ubuntu-специфично·
вообще ознакомьтесь с этим документом, на который выводит google при вводе ключевых слов: http://wiki.debian.org/SSDoptimization

[Mirror]

для Debian'а оно не подходит

оно подходит для ext4·
оно — это изменение параметра монтирования "commit"·
переопределение же этого параметра кем-то/чем-то — судя по всему, ubuntu-специфично·
вообще ознакомьтесь с этим документом, на который выводит google при вводе ключевых слов: http://wiki.debian.org/SSDoptimization

Да, используется ext4. Диски не SSD.

А может ли помочь в данном случае переход на аппаратный RAID?

[sash-kan]

Mirror
а вы рекомендации из приведённой ссылки опробовали?

А может ли помочь в данном случае переход на аппаратный RAID?

смотря в чём это должно помочь·
исправить значение параметра монтирования ext4 "commit" это явно не поможет·
да и переделать ext4 в ext3 — то же вряд ли·

[Mirror]

Mirror
а вы рекомендации из приведённой ссылки опробовали?

А может ли помочь в данном случае переход на аппаратный RAID?

смотря в чём это должно помочь·
исправить значение параметра монтирования ext4 "commit" это явно не поможет·
да и переделать ext4 в ext3 — то же вряд ли·

Это ведь не самоцель. Имеется в виду, исправить ситуацию с чрезмерным увеличением времени отклика сервера в связи с загрузкой дискового ввода-вывода процессами обслуживания программного RAID'а. Ясное дело, что этих процессов не будет, но не будет ли такой же ситуации на уровне контроллера.

Я попробую рекомендации, которые были приведены по ссылке. Надеюсь, это поможет.

[Mirror]

Что-то от выставление таких параметров не наблюдается улучшения. Часто jbd2/md2-8 занимает весь дисковый ввод-вывод, php-fpm зависает. При этом vmstat показывает большой процент на время, которое процессор ожидает завершения ввода-вывода. Таким образом, вопрос про аппаратный RAID становится особенно актуальным.

[mailman137]

А кем/чем определено использование именно ext4 в Вашем конкретном случае?
Я могу Вам пообещать смоделировать ситуацию, подобную Вашей; но только не раньше выходных.
Чисто аппаратному RAID, IMHO, пофигу, какую файловую систему Вы будете наносить на раздел
устройства, сформированного из-под подобного контроллера.
Пока что, честно, я запамятовал, наносил ли я ext4 на LinuxRAID1.

[Mirror]

ext4 поставили сотрудники хостинг-провайдера.

Спасибо за желание помочь )

Сейчас, могу сказать, ситуация стабилизировалась. Причем, решающую роль сыграло решение, которое, казалось бы, не должно было ее сыграть - связь для меня лично очень неявная. Мы отказались от использования APC Cache для кеширования переменных в PHP в пользу Memcache. И проблема с софтовым RAID'ом решилась.

Я даже не знаю, что предполагать. Можно было бы предположить какой-нибудь активный своппинг, но vmstat вроде бы показывал si=0, so=0... Но факт остается фактом - после отказа от APC проблема исчезла.

Детектировать медлительность APC удалось с помощью профайлера XHProf. Если когда-нибудь человечество столкнется с подобной проблемой - профилирование кода очень помогает.

[mailman137]

Мне чертовски не достает квалификации до Вашей.
Я, безусловно, изучу Ваши изыскания, изложеннные в Вашем последнем посте;
только вот я не счел бы излишним изначально обкатывать серверные решения
в локальном варианте.

[Mirror]

Это, конечно, верно, но в локальном варианте трудно создать такие же условия, как на основном сервере. Есть разные утилиты для нагрузочных тестов, но как правило они не способны создать нагрузку, сравнимую с реальной - из-за проблем с несколькими тысячами исходящих соединений с одного компьютера; еще с их помощью трудно тестировать запросы, изменяющие состояние сервера, особенно эмулировать много разных сессий.

А проблем с APC кешем я вообще не ожидал, и при тестировании они абсолютно не проявлялись - помогло только профилирование в реальных условиях.

Теперь будет опыт - использовании этого модуля для хранения переменных может вызвать проблемы, в то время как с Memcache проблем нет.

[mailman137]

Имеется в виду, исправить ситуацию с чрезмерным увеличением времени отклика сервера в
связи с загрузкой дискового ввода-вывода процессами обслуживания программного RAID'а

Я вот тут подцепил дополнительно к одной машине два SSD на фэйковый навесной контроллер
просто в режиме SATA Host Adapter, и сформировал на них LinuxRAID1; на котором разметил пару
разделов, на один из которых нанес ext4 под корень системы.
Ко второй машине я прилепил дополнительно два HDD на аппаратный RAID-контроллер LSI SAS 9260-8i,
на котором инициализировал виртуальный диск с RAID1, на котором тоже разметил пару разделов с нанесением ext4.
Так вот, после установки ОС что на одну, что на другую машину я не увидел никакой загрузки I/O дисковой подсистемы.
Естественно, я не запускал никаких серверных приложений (кроме sshd) и не имитировал массовые обращения к серверу.
Мне сдается, что само по себе обслуживание программнного RAID не есть первоопределяющая причина тормозов.

[Mirror]

Имеется в виду, исправить ситуацию с чрезмерным увеличением времени отклика сервера в
связи с загрузкой дискового ввода-вывода процессами обслуживания программного RAID'а

Я вот тут подцепил дополнительно к одной машине два SSD на фэйковый навесной контроллер
просто в режиме SATA Host Adapter, и сформировал на них LinuxRAID1; на котором разметил пару
разделов, на один из которых нанес ext4 под корень системы.
Ко второй машине я прилепил дополнительно два HDD на аппаратный RAID-контроллер LSI SAS 9260-8i,
на котором инициализировал виртуальный диск с RAID1, на котором тоже разметил пару разделов с нанесением ext4.
Так вот, после установки ОС что на одну, что на другую машину я не увидел никакой загрузки I/O дисковой подсистемы.
Естественно, я не запускал никаких серверных приложений (кроме sshd) и не имитировал массовые обращения к серверу.
Мне сдается, что само по себе обслуживание программнного RAID не есть первоопределяющая причина тормозов.

Ясно, спасибо. Мы тоже пришли к выводу, что первопричина не в софтовом RAID'е. После отказа от APC Cache все наладилось. Сейчас для кеширования байткода мы используем XCache, а для хранения переменных - Memcache.

[mailman137]

Есть разные утилиты для нагрузочных тестов, но как правило они не способны
создать нагрузку, сравнимую с реальной - из-за проблем с несколькими тысячами
исходящих соединений с одного компьютера; еще с их помощью трудно тестировать
запросы, изменяющие состояние сервера, особенно эмулировать много разных сессий.

Мне трудно судить, для каких именно целей люди в том или ином случае хостятся,
но только если Вашей задачей является потенциально высокопосещаемый веб-ресурс;
лично мне было бы интересно потестить таковой (свой) ресурс изо-всех сил.
Есть ли в Вашем арсенале вещи типа ab, httperf или siege?
Я это спрашиваю лишь в плане "помощи клуба" и технического интереса.

Сейчас, могу сказать, ситуация стабилизировалась.

Однозначно, рад.

[Mirror]

Есть ли в Вашем арсенале вещи типа ab, httperf или siege?

Да, используем siege. Но с его помощью не получилось создать такую нагрузку, с которой мы столкнулись в итоге )

[mailman137]

Я прошу прощения, что навещаю тему лишь наскоками; вот только создать нагрузку
на Ваш сервер не составляет никакого труда, раз уж Вы состоите в Сообществе
(только заявите). По Вашему сценарию (если захотите) Ваш сервер могут пробомбить
десять-двадцать-пятьдесят хостов с максимальным количеством коннектов. Мало ли
интересующихся...Заодно, посмотрим, насколько могуч Ваш хостинг-провайдер.
А там можно и анализировать нагрузку на дисковую подсистему...

[Mirror]

Я прошу прощения, что навещаю тему лишь наскоками; вот только создать нагрузку
на Ваш сервер не составляет никакого труда, раз уж Вы состоите в Сообществе
(только заявите). По Вашему сценарию (если захотите) Ваш сервер могут пробомбить
десять-двадцать-пятьдесят хостов с максимальным количеством коннектов. Мало ли
интересующихся...Заодно, посмотрим, насколько могуч Ваш хостинг-провайдер.
А там можно и анализировать нагрузку на дисковую подсистему...

Да я тоже не слишком регулярно посещаю тему ))

Буду иметь в виду в другой раз ) Теперь-то нагрузка постоянная, можно ставить эксперименты, следить за эффектом.

[Ленивая Бестолочь]

i	Уведомление от модератора
	перемещу в администрирования, оставив ссылку в debian. т.к. дебиан-специфичного тут нет, а в адм. возможно кто-нибудь заинтересуется.