Tengo un servidor de archivos CentOS 6.4 que ejecuta NFS 4 y sirve a un par de sistemas de archivos XFS. Hay unas pocas docenas de clientes conectados a él. Hoy la velocidad se ralentizó para los clientes: los clientes se bloqueaban o solo respondían después de unos minutos al acceder al recurso compartido NFS montado desde el servidor. En el servidor mismo pude acceder a los sistemas de archivos compartidos sin problemas. El problema desapareció después de unas cuatro horas, pero no sé por qué; consulte a continuación.
topmostró varios migrationprocesos y xfssyncdprocesos que consumen cantidades inusuales de CPU, saltando entre 0% y hasta 100% cada pocos segundos. Ningún otro proceso estuvo notablemente activo. El uso general de la CPU informado por top fue bajo, así:
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
No he podido encontrar nada en línea que hable sobre esto en particular, aparte posiblemente de una entrada de soporte de RHEL que está en su sección exclusiva para suscriptores y que no puedo ver.
Corrí service nfs restart. Luego service nfs statusmostró demonios en ejecución, excepto nfsd dead but subsys locked. Después de otro reinicio, esto desapareció y nfsd se estaba ejecutando, pero los clientes seguían colgados.
Probé algunas cosas sugeridas para problemas relacionados con xfssyncd:
1) mount –o remount /mnt/datasobre los fs exportados. Curiosamente, este comando tardó aproximadamente un minuto en ejecutarse y durante este tiempo los procesos "salvajes" se calmaron. Pero una vez que el comando terminó de ejecutarse, los procesos volvieron a tener un uso elevado de la CPU.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecspara cambiar el intervalo de sincronización para xfssyncd. Esto no hizo ninguna diferencia notable, lo cual no es demasiado sorprendente ya que fs está ocupado con clientes NFS y el problema debe ser otra cosa.
Tuve un problema con este servidor hace 3 semanas en el que un archivo .nfsNNN (de un archivo eliminado todavía está abierto y se puede acceder a él) se estaba llenando rápidamente con un mensaje de error en bucle en un cliente. Matar el proceso problemático solucionó la desaceleración de NFS. [Sin embargo, el servidor de archivos volvió a ralentizarse un par de días después sin ese problema con el archivo .nfsNNN, y finalmente tuve que reiniciarlo. En ese momento vi algunos procesos con niveles de CPU inusuales, pero no noté cuáles eran y ahora no recuerdo si eran los mismos que el problema actual.]
Hoy volví a buscar archivos .nfsNNN abiertos que tal vez fueran problemas, pero no encontré ninguno. Eliminé algunos de hace unos meses, pero no se estaban modificando actualmente, así que pensé que no eran un problema. No noté ninguna diferencia después de eliminar estos archivos.
Aproximadamente una hora después de probar las diversas cosas anteriores, el servidor volvió a la normalidad y los procesos migrationy xfssyncdya no tenían un uso elevado de la CPU. No sé qué cambió, pero me gustaría intentar resolverlo ya que parece que podría volver a suceder.
Gracias por cualquier sugerencia.
-METRO
Respuesta1
Tengo un RHEL 6.10 con problemas similares. Lo único que parece ayudar es eliminar procesos sftp de usuario de larga duración en el cliente NFS. Estos eran procesos que los clientes SFTP basados en GUI (por ejemplo, WinSCP, Nimble Commander) mantenían abiertos durante muchas horas (> 10 horas).
El monitoreo muestra cierta actividad del cliente NFSv3 que coincide con el problema, pero la actividad en realidad es menor que alguna otra actividad típica en otros clientes (hay > 100 clientes) que no causan el problema.
En realidad, tampoco se han realizado muchas E/S.
ACTUALIZACIÓN 10/12/2019: La causa principal parece haber sido las cuotas XFS en el servidor NFS. Los directorios personales de los usuarios tienen cuotas impuestas, con un límite flexible de 2 GB inferior al límite estricto. Algunos usuarios intentaron instalar una Anaconda Python completa, que superó el límite flexible. El instalador de Anaconda no parecía tener forma de interceptar las advertencias y seguía descargando archivos más allá del límite flexible. Esto generó una tasa masiva de advertencias de cuotas, lo que atascó completamente el sistema y lo hizo dejar de responder.
Digo "parece" porque la evidencia es circunstancial. Cuando los usuarios intentaron instalar en un directorio sin cuota, todo salió bien.