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

Медленный системный вызов open () в Linux

У нас возникли проблемы с нашим файловым сервером Samba, работающим на Debian Etch с ядром Linux 2.6.16. Это старый сервер Dell PowerEdge 2650, но у него никогда не было такой проблемы, и проблема началась сегодня утром, без каких-либо изменений в конфигурации или других изменений.

Хотя проблема проявляется по-разному, все они, возможно, объясняются очень медленным завершением системного вызова open (). Вот разновидность "cat logon.bat", где файл находится в локальной файловой системе ext3:

$ sudo strace -p 3548 -tt 
Process 3548 attached - interrupt to quit
11:20:40.563088 open("logon.bat", O_RDONLY|O_LARGEFILE) = 3
11:21:00.070660 fstat64(3, {st_mode=S_IFREG|0664, st_size=44, ...}) = 0
11:21:00.070923 read(3, "cscript \\\\staff\\netlogon\\logon.v"..., 4096) = 44
11:21:00.085676 write(1, "cscript \\\\staff\\netlogon\\logon.v"..., 44) = 44
11:21:00.085906 read(3, "", 4096)       = 0
11:21:00.086053 close(3)                = 0
11:21:00.086222 close(1)                = 0
11:21:00.086382 exit_group(0)           = ?
Process 3548 detached

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

Сервер был перезагружен, но проблема не исчезла. В kern.log ничего не сообщается, и оборудование не сообщает о сбоях.

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

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

Обновить

Я должен был указать, что эта конкретная файловая система находится на устройстве Apple Xserve RAID (подключенном через FiberChannel). Инструмент RAID Admin горит зеленым светом состояния для всех дисков, а также для массива в целом, и в журнале нет никаких событий, указывающих на какие-либо проблемы.

Святые жесткие диски, Бэтмен! Это МЕДЛЕННО!

Это действительно похоже на аппаратные проблемы низкого уровня на жестких дисках. Я ожидаю, что если вы подключите другой диск (usb, cdrom, local SATA IDE), вы не увидите этих проблем? Если вы еще не пробовали это сделать, я рекомендую вам это сделать.

Если вы по-прежнему видите проблемы с разными дисками, возможно, стоит попробовать переустановить ОС (или просто загрузить ее с образа knoppix / похожего на тест). Также может быть полезно увидеть параметры монтирования и вывод «бесплатно».

Это работает на одном из raid-контроллеров dell (похоже, это будет что-то PERC / 4something). Если это так, драйвер ядра мегарайда, похоже, вообще не реагирует и не сообщает о проблемах с диском, вам необходимо установить Материал Dell OpenManage чтобы увидеть, что происходит на аппаратном уровне. Эта ветка предлагает после установки использовать такие команды, как

omreport storage controller 
omreport storage adisk controller=0 
omreport storage vdisk controller=0 

Вот документация Dell по omreport.

Более новые контроллеры Megaraid SAS (PERC / 5) могут использовать только MegaCLI для управления ими.