nie-intensywna alternatywa dla lsof?

12

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ć lsofpod 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 -bi -n. Oto pełne polecenie, ponieważ działam pod collectd:

sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l
Michael Martinez
źródło

Odpowiedzi:

12

Prawdopodobnie nie musisz rozpoznawać adresów sieciowych dla gniazda, więc przynajmniej użyj -nprzełącznika. Wtedy możesz też chcieć, więc pomiń operacje blokowania za pomocą -b.

Te 2 pierwsze przełączniki powinny naprawdę przyspieszyć.

A potem, -laby uniknąć rozwiązywania problemów. I -Laby uniknąć liczenia linków. Itd. Zobacz mężczyznę .

Alternatywnie, w Linuksie, możesz stworzyć skrypt, aby po prostu policzyć linki w /proc/<PID>/fdnastępujący sposób:

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

Benoit
źródło
Iway get - find: /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ąć?
BG Bruno,
2
@BrunoBG: spróbuj:echo /proc/*/fd/* | wc -w
Olivier Dulac
Dzięki @OlivierDulac to było oczywiste :-)
BG Bruno
dobre propozycje, ale już było za pomocą -n -B opcje .... muszę więcej sugestii
Michael Martinez
1
@OlivierDulac może nie działać, jeśli masz bardzo dużą liczbę FD.
Benoît,
5

Robisz to źle.

Od man proc

   /proc/sys/fs/file-nr

Ten plik (tylko do odczytu) zawiera trzy liczby: liczbę przydzielonych uchwytów plików (tj. Liczbę aktualnie otwartych plików); liczba wolnych uchwytów plików; oraz maksymalną liczbę uchwytów plików (tj. taką samą wartość jak / proc / sys / fs / file-max). Jeśli liczba przydzielonych uchwytów plików jest bliska maksimum, należy rozważyć zwiększenie tego maksimum. Przed Linuksem 2.6 jądro alokowało uchwyty plików dynamicznie, ale nie zwalniało ich ponownie. Zamiast tego uchwyty wolnych plików były przechowywane na liście w celu realokacji; wartość „wolnych uchwytów plików” wskazuje rozmiar tej listy. Duża liczba wolnych uchwytów plików wskazuje, że w przeszłości istniało maksimum w użyciu otwartych uchwytów plików. Od Linuksa 2.6 jądro zwalnia zwolnione uchwyty plików i „

Pierwsza wartość, jeśli kot, który daje dokładnie to, kim jesteś po pojawieniu się.

Dla przypomnienia, nie udało mi się lsofdopasować wyniku nawet przy odrobinie kruszenia, ale rozumiem, czy to jest to, co jądro mówi, że jest bardziej autorytatywne niż lista, którą otrzymujesz lsof.

Matthew Ife
źródło
1
Oto moje wyjście lsof: [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, że lsofobejmuje 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-nrjest droga, w przeciwnym razie potrzebujesz lsof lub równoważnego.
Michael Martinez,
Spróbuj inode-nrzamiast tego w tej samej lokalizacji.
Matthew Ife,