У меня есть файловый сервер CentOS 6.4 под управлением NFS 4, обслуживающий пару файловых систем XFS. К нему подключено несколько десятков клиентов. Сегодня он замедлился до сканирования для клиентов - клиенты зависали или отвечали только через несколько минут при доступе к смонтированному общему ресурсу NFS с сервера. На самом сервере я мог без проблем получить доступ к общим файловым системам. Проблема исчезла примерно через четыре часа, но я не знаю почему - см. Ниже.
top показал несколько migration процессы и xfssyncd процесс, потребляющий необычное количество ЦП, скачок от 0% до 100% каждые несколько секунд. Никакие другие процессы не были заметно активными. Общее использование процессора, о котором сообщает top, было низким, например:
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Мне не удалось найти что-либо в Интернете, в котором говорилось бы об этом, в частности, кроме, возможно, записи о поддержке RHEL, которая находится в их разделе только для подписчиков, и я не вижу.
Я побежал service nfs restart. затем service nfs status показали запущенные демоны, кроме nfsd dead but subsys locked. После очередного перезапуска это исчезло, и nfsd работал, но клиенты все еще зависали.
Я пробовал некоторые вещи, которые предлагались для решения проблем, связанных с xfssyncd:
1) mount –o remount /mnt/data на экспортируемых фс. Интересно, что выполнение этой команды заняло около минуты, и за это время «дикие» процессы успокоились. Но как только команда завершила выполнение, процессы вернулись к высокой загрузке процессора.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs чтобы изменить интервал синхронизации для xfssyncd. Это не дало заметной разницы, что неудивительно, поскольку fs занята клиентами NFS и проблема должна быть в другом.
У меня была проблема с этим сервером 3 недели назад, когда файл .nfsNNN (из удаленного файла все еще открыт и к нему осуществляется доступ) быстро заполнялся сообщением об ошибке зацикливания на клиенте. Устранение проблемного процесса исправило замедление работы NFS. [Однако через пару дней файловый сервер снова замедлился без такой проблемы с файлом .nfsNNN, и мне в конце концов пришлось просто перезагрузить его. В то время я видел некоторые процессы с необычными уровнями ЦП, но не заметил, что они собой представляют, и не могу вспомнить, были ли они такими же, как текущая проблема.]
Сегодня я снова поискал открытые файлы .nfsNNN, которые, возможно, были проблемами, но не нашел. Я удалил некоторые из них несколько месяцев назад, но в настоящее время они не изменялись, поэтому решил, что это не проблема. После удаления этих файлов разницы не заметил.
Примерно через час после выполнения различных действий, описанных выше, сервер вернулся в нормальное состояние и migration и xfssyncd процессы больше не имели высокой загрузки ЦП. Я не знаю, что изменилось, но я хотел бы попытаться выяснить это заранее, поскольку кажется, что это может произойти снова.
Спасибо за любые предложения.
-M
У меня RHEL 6.10 с похожими проблемами. Единственное, что, кажется, помогает, - это убивать долго выполняющиеся пользовательские процессы sftp на клиенте NFS. Эти процессы оставались открытыми с помощью клиентов SFTP на основе графического интерфейса (например, WinSCP, Nimble Commander) в течение многих часов (> 10 часов).
Мониторинг показывает, что некоторая активность клиента NFSv3 совпадает с проблемой, но на самом деле активность ниже, чем какая-либо другая типичная активность на других клиентах (имеется> 100 клиентов), что не вызывает проблемы.
Кроме того, на самом деле не так много операций ввода-вывода.
ОБНОВЛЕНИЕ 2019-12-10: Основная причина, похоже, заключалась в квотах XFS на сервере NFS. На домашние каталоги пользователей наложены квоты с мягким пределом на 2 ГБ ниже жесткого. Некоторые пользователи пытались установить полную версию Anaconda Python, которая превысила мягкий предел. Установщик Anaconda, похоже, не мог перехватить предупреждения и продолжал загружать файлы после мягкого ограничения. Это привело к появлению большого количества предупреждений о квотах, полностью завалило систему и сделало ее невосприимчивой.
Я говорю «кажется», потому что доказательства являются косвенными. Когда пользователи попытались установить в каталог без квоты, все прошло нормально.