[NFS IP]-m команда потребляет 100% ЦП

Вопрос или проблема

Я испытываю периодическое снижение производительности на сервере NFS с использованием хранилища Unity.
Клиент NFS – Rocky Linux 8.6. Когда записи NFS замедляются, я наблюдаю следующий вывод в top:

top - 18:35:59 up 15 days,  5:19,  5 users,  load average: 3.60, 3.62, 3.55
Tasks: 770 total,   3 running, 767 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  3.2 sy,  0.0 ni, 96.6 id,  0.0 wa,  0.1 hi,  0.1 si,  0.0 st
MiB Mem : 128107.2 total,  10128.1 free,  11354.3 used, 106624.8 buff/cache
MiB Swap:  16384.0 total,  16075.5 free,    308.5 used. 111756.2 avail Mem
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2118761 root      20   0       0      0      0 R  99.7   0.0  93:01.44 [NFS IP]-m

Этот процесс невозможно завершить даже с помощью kill -9. Ниже приведены дополнительные выводы команд:

ps -eo pid,ppid,state,comm | grep 2118761
2118761       2 R [NFS IP]-m

lsof -p 2118761
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/0/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/0/gvfs
      Output information may be incomplete.
COMMAND       PID USER   FD      TYPE DEVICE SIZE/OFF NODE NAME
192.168.4 2118761 root  cwd       DIR    8,3     4096    2 /
192.168.4 2118761 root  rtd       DIR    8,3     4096    2 /
192.168.4 2118761 root  txt   unknown                      /proc/2118761/exe

strace -p 2118761
strace: attach: ptrace(PTRACE_SEIZE, 2118761): Operation not permitted
Даже после остановки связанных сервисов (MySQL, nfs-client.target, rpcbind) я не могу отмонтировать затронутую точку монтирования:

umount /data
umount.nfs4: /data: устройство занято

umount -f /data
umount.nfs4: /data: устройство занято

Через некоторое время проблема разрешилась сама собой. Однако, так как это происходит периодически, я хотел бы понять коренную причину. Любые инсайты или руководство будут очень признательны.

Спасибо.

Ответ или решение

Ваш сценарий, связанный с высокими нагрузками процессора в NFS-сервере на платформе Unity storage, можно трактовать, исходя из данных, которые вы представили. Давайте рассмотрим теоретическую основу, пример и возможные решения.

Теория (Theory)

Начнем с понимания, что такое NFS. NFS, или Network File System, — это распределенная файловая система, которая позволяет пользователям просматривать, а при необходимости и изменять файлы на удаленных серверах так, как если бы они находились на локальной машине. NFS широко используется для организации совместного доступа к файлам в сетевых средах.

Характеристика вашей проблемы связана с тем, что некая операция с IP-маркировкой, указана как [NFS IP]-m, потребляет около 100% ресурсов CPU. В топовом выводе видно, что вышеназванный процесс работает с высоким приоритетом, что может указывать на то, что он является частью системной службы или ядра, особенно учитывая, что процесс имеет PID 2118761 и не может быть завершён даже с использованием kill -9.

Скорее всего, [NFS IP]-m — это поток ядра или модуль ядра, связанный с NFS. Если процесс невозможно завершить сигналом kill -9 или количество использования процессора значительно, это может указывать на проблему в ядре или системе ввода-вывода. Такие проблемы, как "зависание" ядра или модуля, часто можно проверить через анализ ядра или логов системы.

Пример (Example)

Ваше окружение работает на Rocky Linux 8.6, который является форком CentOS. Ключевое, что видно из лога top, это:

  • Нагрузка на CPU в основном связана с системой (3.2% sy), а не пользовательскими процессами.
  • Процесс NFS, судя по всему, не имеет текущее место или файловый дескриптор, показанные командой lsof.
  • Заблокированные ресурсы демонстрируют проблему с FUSE, который отвечает за пользовательские файловые системы в пространстве пользователей.

Корреляция между процессом NFS и Unity storage предполагает оценку работы, связанной с сетевыми и дисковыми I/O операциями. Часто проблемы в таких системах могут возникать из-за ошибок в совместимости клиента и сервера NFS, проблем с конфигурацией, или из-за чрезмерных ожиданий на сервере.

Применение (Application)

  1. Диагностика конфигурации: Первым шагом будет проверка всех активных конфигураций NFS, как на сервере, так и на клиенте. Оцените настройки монтирования: используемые параметры, такие как rsize, wsize, время ожидания и повторные попытки соединения. Активное логирование на сервере может предоставить дополнительную информацию.

  2. Логирование ядра: Взгляните на системные логи, особенно dmesg и /var/log/messages для поиска ошибок, связанных с работой NFS. Если в логах обнаруживаются ошибки, это может указать на аппаратную проблему или несовместимость прошивки с Unity storage.

  3. Мониторинг системы: Используйте инструменты мониторинга, такие как iostat, vmstat и sar, чтобы понять, происходит ли высокая нагрузка на сервер в это время. Проверьте, есть ли значительные задержки ввода-вывода или использование ресурсов.

  4. Обновление и патчи: Убедитесь, что у вас установлены последние обновления для операционной системы и NFS, включая любые обновления ядра. Инструменты, такие как yum или dnf, могут помочь обеспечить регулярные обновления.

  5. Сетевое взаимодействие: Просмотрите сетевые логи для исключения потерь пакетов или неисправностей маршрутизации. Работая в сетевой среде, очень важно удостовериться, что конфигурация сети между клиентом и сервером работает правильно.

  6. Обратитесь за поддержкой: Рассмотрите возможность обращения за поддержкой к поставщику хранилища (Dell EMC для Unity storage) или сообществу Rocky Linux для получения специализированных рекомендаций или выявления известных проблем.

Таким образом, системный подход к диагностике и решение проблем NFS обеспечит стабильную работу и позволит избежать дальнейших возникновений аналогичных ситуативных перегрузок CPU.

Оцените материал
Добавить комментарий

Капча загружается...