alternativa no intensiva en CPU a lsof?

12

Ejecutamos un clúster Apache Cassandra donde cada host tiene unos cientos de miles de archivos abiertos en un momento dado.

Nos gustaría ser capaz de obtener un recuento de archivos abiertos a intervalos periódicos y alimentar este número en el grafito , pero cuando nos encontramos lsofbajo collectd, acaba de tomar unos minutos para completar y masticando una cantidad excesiva de CPU en el ínterin .

Me pregunto si hay un medio alternativo y más amigable para obtener los mismos datos que proporciona lsof, o incluso una forma de ejecutar lsof que no se comerá en la CPU tan notablemente. (Aunque supongo que este último método probablemente tardaría mucho más en completarse de lo que lo hace actualmente ... no es lo ideal).

¿Quizás el núcleo mantiene alguna variable en algún lugar que contiene el número de archivos abiertos? Ilusiones?

Actualizar:

En respuesta a una de las respuestas, ya estamos usando las banderas -by -n. Aquí está el comando completo ya que lo tengo ejecutándose collectd:

sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l
Michael Martinez
fuente

Respuestas:

12

Probablemente no necesite resolver las direcciones de red para el socket, así que al menos use el -nconmutador. Entonces es posible que también desee omitir las operaciones de bloqueo con -b.

Estos 2 primeros interruptores realmente deberían hacerlo más rápido.

Y luego -lpara evitar la resolución de uids. Y -Lpara evitar contar enlaces. Etc. Ver al hombre lsof .

Alternativamente, con Linux, puede hacer un script para simplemente contar los enlaces de /proc/<PID>/fdesta manera:

find /proc -mindepth 3 -maxdepth 3 -type l | awk -F/ '$4 == "fd" { s++ } END { print s }'

Benoît
fuente
Siempre obtengo - find: /proc/{{number}}/fd/5': No such file or directory find: / proc / {{number}} / fdinfo / 5 ': No existe tal archivo o directorio - Q @ Benoît ¿cómo puedo evitar eso?
BG Bruno
2
@BrunoBG: prueba:echo /proc/*/fd/* | wc -w
Olivier Dulac
Thx @OlivierDulac que era obvio :-)
BG Bruno
buenas sugerencias, pero ya he estado usando las opciones -n y -b ... Necesito más sugerencias
Michael Martinez
1
@OlivierDulac puede no funcionar si tiene una gran cantidad de fd.
Benoît
5

Lo estás haciendo mal.

Desde man proc

   /proc/sys/fs/file-nr

Este archivo (de solo lectura) contiene tres números: el número de identificadores de archivo asignados (es decir, el número de archivos actualmente abiertos); el número de identificadores de archivos libres; y el número máximo de identificadores de archivo (es decir, el mismo valor que / proc / sys / fs / file-max). Si el número de identificadores de archivo asignados es cercano al máximo, debería considerar aumentar el máximo. Antes de Linux 2.6, el archivo asignado al núcleo se maneja dinámicamente, pero no los volvió a liberar. En cambio, los identificadores de archivos libres se mantuvieron en una lista para la reasignación; el valor de "manejadores de archivos libres" indica el tamaño de esa lista. Una gran cantidad de identificadores de archivos libres indica que hubo un pico pasado en el uso de identificadores de archivos abiertos. Desde Linux 2.6, el núcleo desasigna los identificadores de archivos liberados y el "

El primer valor si tu gato te da exactamente lo que eres después de que aparezca.

Para el registro, no pude hacer que la lsofsalida coincida incluso con una cierta cantidad de falsificación, pero deduzco que si eso es lo que dice el núcleo es más autoritario que la lista que obtieneslsof todos modos.

Matthew Ife
fuente
1
Aquí está mi salida lsof: [root@ec2- cassandra101 ~]$ time lsof -b -n -w -l -L | stdbuf -i0 -o0 -e0 wc -l 1018065. Esto es lo que dice file-nr: [root@ec2- cassandra101 ~]$ cat /proc/sys/fs/file-nr 2784 0 3093428. La gran discrepancia (1,000,000+ versus 2784) se debe al hecho de que lsofincluye todas las cosas que no tienen un descriptor de archivo asociado: archivos de biblioteca, excecutables, etc. Entonces, si solo está interesado en descriptores de archivos, entonces file-nres el camino a seguir, de lo contrario necesita lsof o equivalente.
Michael Martinez
Intente inode-nren su lugar en el mismo lugar entonces.
Matthew Ife