Как определить, вызывает ли ввод-вывод Linux-диска чрезмерные (> 1 секунды) зависания приложений

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

• Какой тип серверного оборудования вы используете? (марка и модель)
• Опишите, пожалуйста, настройку хранилища (RAID-контроллер, конфигурацию кеша, количество и расположение дисков)
• Какую операционную систему ты используешь? Были бы полезны версии дистрибутива и ядра.

Почему я прошу эту информацию?

Настройка оборудования и уровень RAID могут ОГРОМНО повлиять на наблюдаемую производительность. Кэширование чтения и записи на аппаратных RAID-контроллерах может и должно быть настроено в соответствии с вашей рабочей нагрузкой и шаблонами ввода-вывода. Операционная система имеет значение, потому что она влияет на рекомендации по инструментам и методы настройки, которые могут быть вам полезны. Различные дистрибутивы и ядра имеют разные настройки по умолчанию, поэтому характеристики производительности у них различаются.

Итак, в этом случае есть несколько возможностей:

• Ваш RAID-массив может не справиться с рабочей нагрузкой (недостаточно шпинделей).
• Или вы могли бы извлечь выгоду из написать кеширование.
• У вас могут быть проблемы с фрагментацией (насколько заполнена файловая система?).
• Вы могли бы иметь неподходящий уровень RAID это противоречит требуемым характеристикам.
• Ваш RAID-контроллер может нуждаться в настройке.
• Возможно, вам придется изменить планировщик ввода-вывода вашей системы и запустить некоторая настройка блочного устройства.
• Вы можете рассмотреть более оптимизированную для производительности файловую систему, например XFS.
• Вы можете удалить журнал и перемонтировать файловые системы как ext2. Это можно сделать на лету.
• У вас могут быть дешевые диски SATA, которые могут испытывать таймауты шины.

Но как есть, у нас недостаточно информации для продолжения.

Ответ: «Да» (ведение журнала ВСЕГДА добавляет задержку :-)

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

Поскольку вы упомянули в своих комментариях к другой ответ что вы не можете провести прямой тест в своей производственной среде (и, предположительно, у вас нет среды разработки / тестирования, которую вы можете использовать), у вас есть еще один вариант: посмотрите статистику вашего диска и посмотрите, сколько времени вы тратите на запись в Журнальное устройство.
К сожалению, это действительно помогает, только если ваше журнальное устройство является дискретным и может быть оснащено отдельно от «основного» диска.

Второй раз сегодня подключаю видео МакКьюзика, но если ты пройдешь сквозь это видео есть отличное обсуждение некоторых работ, которые должна выполнять журналирующая файловая система (и ее влияния на производительность).
Непосредственно полезно / актуально для вас и вашего конкретного вопроса, но дает отличные общие сведения о файловых системах и ведении журнала.

Что ж, один простой тест - смонтировать эту ext3 fs как ext2, а затем профилировать производительность приложения.

Я предполагаю, что есть какой-то другой процесс, который на какое-то время потребляет дисковые операции ввода-вывода. iotop может помочь вам определить его, если у вас достаточно недавнее ядро.

Если это так, то дело не в файловой системе, не говоря уже о журналировании. Именно планировщик ввода-вывода отвечает за арбитраж между конфликтующими приложениями. Простой тест: проверьте текущий планировщик и попробуйте другой. Это можно сделать на лету, без перезапуска. Например, у меня на рабочем столе проверить первый диск (/dev/sda):

cat /sys/block/sda/queue/scheduler
=>  noop deadline [cfq]

показывает, что он использует CFQ, который является хорошим выбором для настольных компьютеров, но не особенно для серверов. Лучше установить крайний срок:

echo 'deadline' > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
=>  noop [deadline] cfq

и подождите несколько часов, чтобы увидеть, улучшится ли ситуация. Если это так, установите его постоянно в сценариях запуска (зависит от дистрибутива)

У меня была эта проблема на Redhat 4 с файловыми системами ext3: многие записи в файловой системе ext3 => большое ожидание при записи другого ext3 FS

С обновлением времени доступа доступ для чтения также можно приостановить => обходной путь: mount -o noatime

С уважением, Джером Д.

Вы можете попытаться отойти от /proc/diskstats к /proc/meminfo: Возможно, ваш буфер обратной записи разрастается и требует очистки. У нас была ситуация, когда буферы обратной записи («грязные») заполнялись быстрее, чем они могли быть записаны. Затем Linux запустил больше потоков сброса, что ухудшило положение. Ограничение допустимой доли грязных буферов перед приостановкой процесса в некоторой степени помогло решить проблему. Другой совет, который у меня есть, - корреляция: зафиксируйте моменты, когда ввод-вывод выполняется медленно, а затем сравните, что еще произошло в то же время. Вы можете попробовать это, например:

while sleep 2
do
    (date; cat /proc/meminfo) >> /tmp/your_logfile
done

И сравните, когда ваше приложение кажется медленным.

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

Раньше у меня были серьезные проблемы ввода-вывода при использовании дисков WD Green с Linux Software RAID. Настоятельно рекомендуется использовать диски WD Red, если это ваша проблема. Если вы используете Greens, по мере старения ваших дисков ваш массив, скорее всего, станет невыносимо медленным, поскольку эти диски постоянно пытаются выключаться и включаться для экономии энергии, вызывая ОГРОМНЫЕ всплески задержки ввода-вывода. Вы в конечном итоге изнашиваете эти диски, потому что они начнут накапливать огромную статистику количества циклов загрузки под S.M.A.R.T.