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

Одним из простых тестов было бы подключить эти ext3 fs как ext2, а затем профилировать производительность приложения.

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

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

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

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

Таким образом, в этом случае есть ряд возможностей:

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

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

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

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

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

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

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

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

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

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

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

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

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

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