Назад | Перейти на главную страницу

Как диагностировать неустойчивое поведение диска?

У меня есть веб-сайт с пользователями lighttpd и CGI-скриптами.

После обновления до Fedora 11 (ext4) доступ к диску стал нестабильным. Сроки python -c 'import cgi' варьируется от 0,1 до почти 10 секунд:

Как я могу диагностировать проблему? (Инструменты, методы, лучшие практики ...)

Обновление 30 июля 2009 г .:
Выяснилось, что несколько процессов CGI забивают диск. После их уничтожения график стабильно находится между 0,02 и 0,03. Все еще не получил ответа как диагностировать такие проблемы.

Если это новая установка, то такие инструменты, как makewhatis, которые используются apropos, могут привести к интенсивному использованию диска. Подождите несколько дней, пока все стабилизируется (updateb, prelink, makewhatis и т. Д.), Тогда, возможно, время будет согласованным.

Это также будет зависеть от того, что вы делаете на сервере, и от того, что на самом деле делает cgi-скрипт, откуда он принимает ввод, размер ввода и т. Д.

Также, если диск очень старый, используйте инструменты диагностики (например, seagate seatools) для поиска проблем с контроллером / плохим сектором. Инструменты также позволят вам при желании восстановить сектор, если диск действительно от Seagate.

Вам действительно нужен / нужен ext4 на рабочем сервере? На мой вкус для сервера это все еще очень плохо.

Единственный способ диагностировать подобную проблему - использовать очень много данных. Ознакомьтесь с vmstat и iostat. Инструмент, о котором я недавно узнал в эта тема является dstat который эффективно сочетает в себе два.

Эта команда, вероятно, будет полезна для проблем, подобных описанной вами:

$ dstat -M app -cdnygl

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

$ dstat -M app -cdn
--most-expensive-- ----total-cpu-usage---- -dsk/total- -net/total-
     process      |usr sys idl wai hiq siq| read  writ| recv  send
bacula-fd        0|  1   0  98   0   0   0| 426k  108k|   0     0 
bash             1|  2   2  96   0   0   0|   0    20k|1460B 1804B
apache2          8|  4   2  94   0   0   0|   0     0 |  76k   15k
                  |  1   3  96   0   0   0|   0     0 |1132B 1034B
apache2          1|  2   2  96   0   0   0|   0  8192B|  11k 3895B
                  |  2   1  96   0   0   0|   0    32k|3322B 1338B
kipmi0           1|  2   2  96   0   0   0|   0     0 |1309B 1146B