alternativa non intensiva alla CPU a lsof?

Eseguiamo un cluster Apache Cassandra in cui ogni host ha alcune centinaia di migliaia di file aperti in qualsiasi momento.

Vorremmo essere in grado di ottenere un conteggio di file aperti a intervalli periodici e di inserire questo numero in grafite , ma quando corriamo lsofsotto collectd, ci vogliono alcuni minuti per completare e masticare una quantità eccessiva di CPU nel frattempo .

Mi chiedo se esiste un modo alternativo e più amichevole per ottenere gli stessi dati che lsof fornisce, o anche un modo di far funzionare lsof che non si consuma nella CPU in modo così evidente? (Anche se presumo che questo ultimo metodo richiederebbe molto più tempo per il completamento di quanto non faccia attualmente ... non è l'ideale).

Forse il kernel mantiene qualche variabile da qualche parte che contiene il numero di file aperti? Pensiero speranzoso?

Aggiornare:

In risposta a una delle risposte, stiamo già utilizzando i flag -be -n. Ecco il comando completo come ho in esecuzione sotto collectd:

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

Probabilmente non è necessario risolvere gli indirizzi di rete per socket, quindi utilizzare almeno lo -nswitch. Quindi potresti anche voler saltare le operazioni di blocco con -b.

Questi 2 primi interruttori dovrebbero davvero renderlo più veloce.

E poi -lper evitare di risolvere gli utenti. E -Lper evitare di contare i collegamenti. Ecc. Vedi l' uomo lsof .

In alternativa, con Linux, potresti creare uno script per contare semplicemente i collegamenti in /proc/<PID>/fdquesto modo:

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

Lo stai facendo male.

A partire dal man proc

   /proc/sys/fs/file-nr

Questo file (sola lettura) contiene tre numeri: il numero di handle di file allocati (ovvero il numero di file attualmente aperti); il numero di handle di file gratuiti; e il numero massimo di handle di file (ovvero lo stesso valore di / proc / sys / fs / file-max). Se il numero di handle di file allocati è vicino al massimo, è consigliabile aumentare il massimo. Prima di Linux 2.6, il file allocato dal kernel viene gestito dinamicamente, ma non li libera di nuovo. Invece gli handle di file gratuiti sono stati mantenuti in un elenco per la riallocazione; il valore "handle di file gratuiti" indica la dimensione di tale elenco. Un gran numero di handle di file gratuiti indica che si è verificato un picco passato nell'utilizzo di handle di file aperti. A partire da Linux 2.6, il kernel dealloca gli handle di file liberati e il "

Il primo valore se apparissi in un gatto che ti dà esattamente quello che stai cercando.

Per la cronaca non sono riuscito a far lsofsì che l' output corrispondesse anche a una certa quantità di confusione, ma mi accontento se questo è ciò che il kernel dice sia più autorevole dell'elenco che si ottiene lsofcomunque.