У меня есть файловый сервер 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на экспортированной fs. Интересно, что эта команда выполнялась около минуты, и за это время «дикие» процессы успокоились. Но как только команда завершила выполнение, процессы вернулись к высокой загрузке процессора.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecsдля изменения интервала синхронизации для xfssyncd. Это не дало заметной разницы, что неудивительно, поскольку fs занята клиентами NFS, и проблема должна быть в чем-то другом.
У меня была проблема с этим сервером 3 недели назад, когда файл .nfsNNN (из удаленного файла, который все еще открыт и к которому осуществляется доступ) быстро заполнялся с циклическим сообщением об ошибке на клиенте. Завершение проблемного процесса исправило замедление NFS. [Однако файловый сервер затем снова начал замедляться через пару дней без такой проблемы с файлом .nfsNNN, и в конечном итоге мне пришлось просто перезагрузить его. В то время я видел несколько процессов с необычными уровнями процессора, но не заметил, что это было, и не могу вспомнить сейчас, были ли они такими же, как текущая проблема.]
Сегодня я снова искал открытые файлы .nfsNNN, которые могли быть проблемами, но ничего не нашел. Я удалил некоторые из них несколько месяцев назад, но в настоящее время они не изменялись, поэтому решил, что они не проблема. Я не заметил никакой разницы после удаления этих файлов.
Примерно через час после того, как я попробовал разные вещи выше, сервер вернулся в нормальное состояние, и migrationпроцессы xfssyncdи больше не имели высокой загрузки процессора. Я не знаю, что изменилось, но я хотел бы попытаться выяснить это заранее, так как, похоже, это может произойти снова.
Спасибо за любые предложения.
-М
решение1
У меня RHEL 6.10 с похожими проблемами. Единственное, что, похоже, помогает, — это завершение долго работающих пользовательских процессов sftp на клиенте NFS. Это были процессы, которые клиенты SFTP на основе GUI (например, WinSCP, Nimble Commander) держали открытыми в течение многих часов (> 10 часов).
Мониторинг показывает некоторую активность клиентов NFSv3, совпадающую с проблемой, но эта активность на самом деле ниже, чем типичная активность на других клиентах (их > 100), которые не вызывают проблему.
На самом деле, не так уж много операций ввода-вывода сделано.
ОБНОВЛЕНИЕ 2019-12-10: Основная причина, по-видимому, заключалась в квотах XFS на сервере NFS. Домашние каталоги пользователей имеют квоты, с мягким ограничением на 2 ГБ ниже жесткого ограничения. Некоторые пользователи пытались установить полную версию Anaconda Python, что превысило мягкое ограничение. Установщик Anaconda, похоже, не имел возможности перехватывать предупреждения и продолжал загружать файлы сверх мягкого ограничения. Это приводило к огромному количеству предупреждений о квотах, полностью затормаживая систему и делая ее неотзывчивой.
Я говорю "кажется", потому что доказательства косвенные. Когда пользователи попробовали установить в каталог без квоты, все прошло нормально.