alternativa não intensiva à CPU para lsof?

Executamos um cluster Apache Cassandra em que cada host tem algumas centenas de milhares de arquivos abertos a qualquer momento.

Gostaríamos de poder obter uma contagem de arquivos abertos em intervalos periódicos e alimentar esse número com grafite , mas quando corremos para lsofbaixo collectd, isso leva alguns minutos para ser concluído e consumir uma quantidade excessiva de CPU enquanto isso. .

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

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

Atualizar:

Em resposta a uma das respostas, já estamos usando os sinalizadores -be -n. Aqui está o comando completo, como o tenho em execução collectd:

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

Você provavelmente não precisa resolver os endereços de rede do soquete; portanto, use pelo menos o -ncomutador. Então você também pode querer ignorar as operações de bloqueio com -b.

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

E então, -lpara evitar a resolução de uids. E -Lpara evitar contar links. Etc. Veja o homem lsof .

Como alternativa, com o Linux, você pode criar um script para simplesmente contar os links /proc/<PID>/fddesta forma:

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

Você está fazendo isso errado.

A partir de man proc

   /proc/sys/fs/file-nr

Esse arquivo (somente leitura) contém três números: o número de identificadores de arquivo alocados (ou seja, o número de arquivos atualmente abertos); o número de identificadores de arquivo gratuitos; e o número máximo de identificadores de arquivo (ou seja, o mesmo valor que / proc / sys / fs / file-max). Se o número de identificadores de arquivo alocados for próximo ao máximo, considere aumentar o máximo. Antes do Linux 2.6, o arquivo alocado pelo kernel gerencia dinamicamente, mas não os libera novamente. Em vez disso, os identificadores de arquivo gratuitos foram mantidos em uma lista para realocação; o valor "identificadores de arquivo gratuitos" indica o tamanho dessa lista. Um grande número de identificadores de arquivo gratuitos indica que havia um pico passado no uso de identificadores de arquivos abertos. Desde o Linux 2.6, o kernel desaloca identificadores de arquivos liberados e os "

O primeiro valor, se você considera que o gato é exatamente o que você é depois que ele aparece.

Para o registro, não consegui que a lsofsaída correspondesse a ela, mesmo com alguma quantidade de falsificação, mas acho que é isso que o kernel diz que é mais autoritário do que a lista de lsofqualquer forma.