Directorio home de usuarios + nfs4: lentitud en el escritorio.

Una de las cosas que mas me gustan de Linux en un entorno de red es la capacidad de que los homes de los usuarios estén centralizados en un servidor de red común, de tal forma que siempre tenemos el mismo escritorio independientemente de la máquina usada. Esto facilita al usuario trabajar sin tener que andar subiendo ficheros a una nube o carpeta concreta de red, y a nosotros hacer copias de seguridad de sus datos y no preocuparnos de recuperar datos del usuario cuando falle físicamente el disco del equipo donde ha estado trabajando.

En nuestro caso siempre hemos usado NFS para montar estos homes, aunque hay mas alternativas. Nunca había habido problema pero cuando cambiamos hace unos años a usar Ubuntu 18 empezaron a aparecer problemas aleatorios de lentitud extrema en los escritorios/navegadores web. Una explicación común es que el aumento de complejidad de los navegadores en los últimos años (y eso es algo de lo que habrá que hablar algún día martillo en mano) los ha convertido en unos artefactos que con sus operaciones de entrada/salida acaban saturando el servidor NFS. Una pista en contra de esta hipótesis es que la lentitud va y viene sin correlación aparente con el número de usuarios instantáneos en la red del centro y que cuando una máquina va lenta, la de al lado no tiene por qué hacer lo mismo. Tenía que haber alguna explicación adicional.

Después de muchas pruebas hemos establecido que cambiar el sistema de montaje de los homes de los clientes de nfs4 a nfs3 mejora enormemente el problema, haciéndolo desaparecer en muchos casos. Vamos a ver las pruebas a realizar cuando tenemos un escritorio/navegador ralentizado para determinar si este cambio en el nfs solucionaría el problema.

Las pruebas que podemos realizar son las siguientes:

• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer el comando "time su <usuario>", siendo "usuario" un usuario que monta su home por NFS, claro está. Hacer lo mismo en un equipo no afectado por el problema. Si en el primero tarda 5 o mas veces que el segundo es un síntoma de que está afectado.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer "wget https://speed.hetzner.de/1GB.bin". Hacer lo mismo en un equipo no afectado por el problema. Es un fichero de prueba de 1Gb para hacer tests de velocidad desde consola. Si la velocidad es similar en ambos puestos podemos descartar que sea un problema de red (bucles de red, problemas de cableado, de switchs, de salida a Internet) y centrarnos en que es un problema de NFS.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y mirar en el syslog buscando errores como:

  NFS: nfs4_reclaim_open_state: Lock reclaim failed!
  NFS: nfs4_reclaim_open_state: unhandled error -10026
  nfs4_reclaim_open_state: 3 callbacks suppressed
      

  Estos errores son síntomas de bloqueos y otros problemas en el montaje NFS.
• Entrar en el servidor NFS y testear la carga con los comandos:

  # atop
  # iotop
  # nfsstat
    

  Buscando sobrecargas en el disco, red o en los procesos nfs.
• Entrar por ssh como root a un puesto donde el escritorio vaya lento y hacer

  # nfsiostat
    

  Comparar el resultado con un equipo no afectado por el problema.

Después de todas estas pruebas, si sospechamos que las causas de la lentitud están relacionadas con el servidor NFS, el siguiente paso es verificar que tipo de montaje usamos en nuestros puestos. Para ello entramos por ssh como root en un equipo de usario y hacemos:

# automount -m

global options: none configured

  Mount point: /home

  source(s):

   type: ldap
   map: ldap:ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es
   ....
   ....
   * | -fstype=nfs4,rw,hard,intr,nodev,nosuid,nolock,rsize=16384,wsize=16384 servidor:/&

La última línea nos dice que el montaje del home esta siendo realizado mediante nfs4. No tiene porque ser igual a la indicada, pero el "nfs4" es revelador. La idea es cambiarla por:

   * | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&

que cambia el montaje del home para que se haga usando nfs3. Esta línea si que debemos ponerla de forma literal, tal cual aparece aquí.

El lugar donde se hace este cambio dependerá de donde configuremos el montaje en nuestro entorno. Para el caso de nuestros centros esto se hace en el directorio ldap, al que accedemos mediante phpldapadmin en el nodo:

cn=/,ou=auto.home,ou=Automount,dc=instituto,dc=extremadura,dc=es

Una vez allí localizamos el atributo "automountInformation", hacemos una copia de su contenido por si las moscas y lo sustitumos por:

* | -fstype=nfs,rw,fg,hard,intr,nodev,nosuid,async,ac,vers=3,fsc servidor:/home/&

Después de esto recargamos el servicio nfs en el servidor principal:

/etc/init.d/nfs-kernel-server reload

Y por último reiniciamos los clientes, dejando que trabajen durante varios días a ver si desaparecen los problemas. En bastantes casos con este sencillo cambio ha sido suficiente.

Calcular y mostrar en orden el tamaño de los "home" de los usuarios

Estamos en buena época para hacer limpieza de home de los usuarios y para ello lo mas adecuado es tener un listado del ranking de ocupación, obteniendo así la información necesaria para decidir que hacer con cada usuario.

Veamos los comandos. El primero nos muestra en tamaño decreciente el tamaño de cada carpeta:

# cd /home
# du -hs * | sort -h -r
108G kane
2,5G ripley
1,8G ash
867M dallas
71M  lambert
65M  parker 
32M  brett

El problema del comando anterior es que no nos muestra las carpetas ocultas (en Unix las que comienzan por "."). Dentro de los homes de los usuarios es allí donde está muchas veces toda la grasa (en forma de cachés, papeleras y ficheros temporales) que hace que ocupen tanto. Para incluir en el listado ese espacio sería:

cd /home/kane
# du -sch .[!.]* * | sort -h -r
108G total
70G  .xenomorfo
8,5G 01-office
5,2G .local
2,1G Descargas
1,3G Desktop
345M .mozilla
304M .wine
161M 99-misc
117M .config
116M .capturas
114M Documentos
103M 03-project
13M .thunderbird
5,1M .exe
3,8M .SMART Technologies Inc
....

Por último, si nos interesa localizar los ficheros mas tochos, filtrando por un tamaño mínimo, podemos usar el comando find:

# cd /home/ripley
# find . -type f -size +100M

Con esto saldrán los ficheros cuyo tamaño sea superior a 100M.

Una vez tengamos toda esta información ya podemos decidir si limpiamos nosotros o damos aviso a los usuarios para que vayan haciendo limpieza ellos mismos.