alternativa não-cpu-intensiva para lsof?

Question

Nós executamos um cluster Apache Cassandra , onde cada host tem algumas centenas de milhares de arquivos abertos a qualquer momento.

Gostaríamos de obter uma contagem de arquivos abertos em intervalos periódicos e alimentar esse número em grafite , mas quando executamos lsof em collectd , ele acaba demorando alguns minutos para ser concluído e mastigando uma quantidade excessiva de CPU nesse meio tempo.

Eu estou querendo saber se existe um meio alternativo e mais amigável de obter os mesmos dados que o lsof fornece, ou até mesmo uma maneira de executar o lsof que não consome CPU de forma tão notável? (Embora eu assuma que este último método provavelmente levaria muito mais tempo para ser concluído do que atualmente ... não é ideal).

Talvez o kernel mantenha alguma variável em algum lugar que contenha o número de arquivos abertos? Pensamento de desejo?

Atualização:

Respondendo a uma das respostas, já estamos usando as sinalizações -b e -n . Aqui está o comando completo como eu estou executando em collectd :

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

    

Answer 1

Provavelmente você não precisa resolver os endereços de rede para o soquete; use pelo menos a opção -n . Então você também pode querer pular as operações de bloqueio com -b .

Esses dois primeiros switches realmente devem torná-lo mais rápido.

E, em seguida, -l para evitar a resolução de uids. E -L para evitar a contagem de links. Etc. Consulte o man lsof .

Alternativamente, com o Linux, você poderia criar um script para simplesmente contar os links em /proc/<PID>/fd desta forma:

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

    

Answer 2

Você está fazendo errado.

De man proc

   /proc/sys/fs/file-nr

This (read-only) file contains three numbers: the number of allocated file handles (i.e., the number of files presently opened); the number of free file handles; and the maximum number of file handles (i.e., the same value as /proc/sys/fs/file-max). If the number of allocated file handles is close to the maximum, you should consider increasing the maximum. Before Linux 2.6, the kernel allocated file handles dynamically, but it didn't free them again. Instead the free file handles were kept in a list for reallocation; the "free file handles" value indicates the size of that list. A large number of free file handles indicates that there was a past peak in the usage of open file handles. Since Linux 2.6, the kernel does deallocate freed file handles, and the "free file handles" value is always zero.

O primeiro valor se você gato que lhe dá exatamente o que você está depois que ele apareceria.

Para o registro eu não pude obter a saída lsof para combiná-la mesmo com alguma quantidade de falsificação, mas eu entendo se é isso que o kernel diz que é mais autoritário do que a lista obtida de lsof .