У нас есть собственная «вычислительная ферма» с примерно 100 серверами CentOS (бесплатное повторное распространение RHEL) 5.7 и 6.5 x86_64. (Мы находимся в процессе обновления всех модулей 5.7 до 6.5.) Все эти машины выполняют два монтирования NFSv4 (с sec = krb5p) на два сервера CentOS 6.5. Один сервер NFS предназначен для домашних каталогов пользователей, другой содержит различные данные для пользовательских процессов.
Случайно одна из клиентских машин попадет в плохое состояние, так что любой доступ к монтированию NFSv4 зависнет (например, «ls»). Это означает, что никто (кроме root) не может войти в систему, и все пользовательские процессы, которым требуется доступ к общим ресурсам, застревают. Другими словами, пока это недетерминировано и не может быть воспроизведено.
У меня включено очень подробное ведение журнала NFS как на клиентах, так и на серверах, но я никогда не получаю никаких ошибок. Однако, когда это состояние запускается, я получаю следующие ошибки трассировки ядра на клиентских машинах:
Mar 25 00:49:48 servername kernel: INFO: task ProcessName:8230 blocked for more than 120 seconds.
Mar 25 00:49:48 servername kernel: Not tainted 2.6.32-431.el6.x86_64 #1
Mar 25 00:49:48 servername kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 25 00:49:48 servername kernel: ProcessName D 0000000000000000 0 8230 8229 0x00000000
Mar 25 00:49:48 servername kernel: ffff8804792cdb68 0000000000000046 ffff8804792cdae8 ffffffffa0251940
Mar 25 00:49:48 servername kernel: ffff88010cdc8080 ffff8804792cdb18 ffff88010cdc8130 ffff88010ea5c208
Mar 25 00:49:48 servername kernel: ffff88047b011058 ffff8804792cdfd8 000000000000fbc8 ffff88047b011058
Mar 25 00:49:48 servername kernel: Call Trace:
Mar 25 00:49:48 servername kernel: [<ffffffffa0251940>] ? rpc_execute+0x50/0xa0 [sunrpc]
Mar 25 00:49:48 servername kernel: [<ffffffff810a70a1>] ? ktime_get_ts+0xb1/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f930>] ? sync_page+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff815280a3>] io_schedule+0x73/0xc0
Mar 25 00:49:48 servername kernel: [<ffffffff8111f96d>] sync_page+0x3d/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81528b6f>] __wait_on_bit+0x5f/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff8111fba3>] wait_on_page_bit+0x73/0x80
Mar 25 00:49:48 servername kernel: [<ffffffff8109b320>] ? wake_bit_function+0x0/0x50
Mar 25 00:49:48 servername kernel: [<ffffffff81135bf5>] ? pagevec_lookup_tag+0x25/0x40
Mar 25 00:49:48 servername kernel: [<ffffffff8111ffcb>] wait_on_page_writeback_range+0xfb/0x190
Mar 25 00:49:48 servername kernel: [<ffffffff81120198>] filemap_write_and_wait_range+0x78/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff811baa3e>] vfs_fsync_range+0x7e/0x100
Mar 25 00:49:48 servername kernel: [<ffffffff811bab2d>] vfs_fsync+0x1d/0x20
Mar 25 00:49:48 servername kernel: [<ffffffffa02cf8b0>] nfs_file_flush+0x70/0xa0 [nfs]
Mar 25 00:49:48 servername kernel: [<ffffffff81185b6c>] filp_close+0x3c/0x90
Mar 25 00:49:48 servername kernel: [<ffffffff81074e0f>] put_files_struct+0x7f/0xf0
Mar 25 00:49:48 servername kernel: [<ffffffff81074ed3>] exit_files+0x53/0x70
Mar 25 00:49:48 servername kernel: [<ffffffff81076f4d>] do_exit+0x18d/0x870
Mar 25 00:49:48 servername kernel: [<ffffffff81077688>] do_group_exit+0x58/0xd0
Mar 25 00:49:48 servername kernel: [<ffffffff81077717>] sys_exit_group+0x17/0x20
Mar 25 00:49:48 servername kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
На этом этапе единственный надежный способ восстановить работоспособность машины - это перезагрузить ее. (И даже для этого требуется жесткий цикл включения питания, поскольку перезагрузка программного обеспечения зависает при попытке отключить файловые системы NFS.)
Это кажется как будто эта проблема связана с процессом, который дает сбой и начинает как сумасшедший записывать данные. Например, segfault, который генерирует огромный файл ядра, или ошибка с плотным циклом печати.
Тем не менее, я попытался воспроизвести эту проблему в лабораторной среде с несколькими процессами «dd», работающими на сервере NFS, но все машины успешно справляются с этим.
Проблема существовала с ядром 2.6.32-431.el6 из CentOS 6.5. На момент постановки вопроса это было довольно старое ядро. Мы просмотрели журнал изменений для ядер RHEL / CentOS и увидели много активности, связанной с NFS. Итак, мы обновили (что было) до новейшего ядра CentOS 6.6, 2.6.32-504.12.2.el6, и с тех пор не сталкивался с этой проблемой.