Prowadzimy klaster Apache Cassandra, w którym każdy host ma kilkaset tysięcy otwartych plików w danym momencie.
Chcielibyśmy, aby być w stanie uzyskać liczbę otwartych plików w regularnych odstępach czasu i nakarmić tę liczbę do grafitu , ale kiedy uruchomić lsof
pod collectd
, kończy się poświęcenie kilku minut na wypełnienie i żucie się dużej ilości CPU w międzyczasie .
Zastanawiam się, czy istnieje alternatywny i bardziej przyjazny sposób na uzyskanie tych samych danych, które zapewnia lsof, czy nawet sposób na uruchomienie lsof, które nie zjadają tak szybko procesora? (Chociaż zakładam, że ta ostatnia metoda prawdopodobnie zajmie znacznie więcej czasu niż obecnie ... nie jest idealna).
Być może jądro zachowuje gdzieś zmienną zawierającą liczbę otwartych plików? Pobożne życzenie?
Aktualizacja:
W odpowiedzi na jedną z odpowiedzi używamy już flag -b
i -n
. Oto pełne polecenie, ponieważ działam pod collectd
:
sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l
/proc/{{number}}/fd/5': No such file or directory find:
/ proc / {{number}} / fdinfo / 5 ': Brak takiego pliku lub katalogu - Q @ Benoît, jak mogę tego uniknąć?echo /proc/*/fd/* | wc -w
Robisz to źle.
Od
man proc
Pierwsza wartość, jeśli kot, który daje dokładnie to, kim jesteś po pojawieniu się.
Dla przypomnienia, nie udało mi się
lsof
dopasować wyniku nawet przy odrobinie kruszenia, ale rozumiem, czy to jest to, co jądro mówi, że jest bardziej autorytatywne niż lista, którą otrzymujeszlsof
.źródło
[root@ec2- cassandra101 ~]$ time lsof -b -n -w -l -L | stdbuf -i0 -o0 -e0 wc -l 1018065
. Oto co mówi file-nr:[root@ec2- cassandra101 ~]$ cat /proc/sys/fs/file-nr 2784 0 3093428
. Duża rozbieżność (ponad 1 000 000 w porównaniu z 2784) wynika z faktu, żelsof
obejmuje wszystkie rzeczy, które nie mają z nimi powiązanego deskryptora pliku: pliki biblioteczne, pliki wykonywalne itp. Jeśli więc interesują Cię tylko deskryptory plików,file-nr
jest droga, w przeciwnym razie potrzebujesz lsof lub równoważnego.inode-nr
zamiast tego w tej samej lokalizacji.