Ulimit w systemie Linux: zlokalizuj limit plików, zanim usługa ulegnie awarii

Usługa, która nagle odmawia nowych połączeń lub pisze „Zbyt wiele otwartych plików”, niekoniecznie ma problem z pamięcią. Może osiągnęła limit deskryptorów plików. W systemie Linux gniazdko, dziennik, plik i czasami pipe zużywają jeden deskryptor.

Komenda ulimit -n wyświetla limit bieżącej powłoki. Nie dowodzi limitu dla już uruchomionej usługi. W przypadku demona zarządzanego przez systemd sprawdź proces, jednostkę i stałą konfigurację przed dokonaniem jakichkolwiek zmian.

Sprawdź limit powłoki oraz limit procesu

W swoim terminalu najpierw rozróżnij limit miękki od limitu twardego. Pierwszy może być obniżony przez proces. Drugi ustala pułap, którego użytkownik nieuprzywilejowany nie może przekroczyć.

ulimit -Sn
ulimit -Hn

Wynik 1024 może być wystarczający dla sesji interaktywnej. Szybko staje się niewystarczający dla proxy, serwera WWW lub aplikacji, która utrzymuje wiele otwartych połączeń. Nie kopiuj wartości znalezionej na forum: zacznij od zmierzenia, co używa usługa.

Zidentyfikuj jej PID, a następnie przeczytaj rzeczywiste stosowane limity:

systemctl show nginx -p MainPID
sudo grep 'Max open files' /proc/1234/limits
sudo ls /proc/1234/fd | wc -l

Zamień 1234 na PID zwrócone przez systemd. Licznik w /proc/1234/fd daje zdjęcie liczby otwartych deskryptorów. Porównaj go z Max open files. Mała różnica lepiej tłumaczy saturację niż prosta wrażenie powolności.

Sprawdź limit systemd przed jego modyfikacją

Usługa systemd nie odzyskuje automatycznie wartości twojej sesji SSH. Jednostka może ustawić LimitNOFILE lub dziedziczyć globalną wartość. Wyświetl rzeczywistą wartość:

systemctl show nginx -p LimitNOFILE
systemctl cat nginx

Jeśli jednostka wyświetla niski limit i logi potwierdzają błędy otwierania, stwórz nadpisanie zamiast modyfikować plik dostarczony przez pakiet:

sudo systemctl edit nginx

Dodaj następnie tę sekcję, z wartością dostosowaną do twojej aplikacji:

[Service]
LimitNOFILE=65535

Dla usługi wystawionej na produkcję, pozostaw drugą sesję SSH otwartą. Błąd w jednostce lub nieudane ponowne uruchomienie nie powinno zostawiać cię bez dostępu. Sprawdź również dokumentację aplikacji: niektóre narzucają swoją własną górną granicę, odmienną od systemd.

Uruchom ponownie, a następnie sprawdź rzeczywistą wartość

Po nadpisaniu, przeładuj konfigurację i uruchom ponownie tylko dotkniętą usługę:

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl show nginx -p LimitNOFILE
systemctl status nginx --no-pager

Na koniec ponownie przeczytaj /proc/PID/limits z nowym PID. Jeśli LimitNOFILE wynosi 65535 w systemd, ale proces pozostaje na 1024, prawdopodobnie patrzysz na stary PID, inną usługę lub pośredniego nadzorcę.

Kontrole do wykonania przed zwiększeniem limitu

• Potwierdź dokładny błąd w journalctl -u nginx lub w logach aplikacyjnych.
• Mierz liczbę otwartych deskryptorów przed i po szczycie obciążenia.
• Zwiększ limit dla konkretnej jednostki, a nie dla wszystkich usług na maszynie.
• Monitoruj połączenia, pliki i gniazdka, które pozostają otwarte: wyciek deskryptorów należy naprawić w aplikacji.

Wyższy limit zapobiega nagłemu zatrzymaniu usługi, ale nie naprawia procesu, który otwiera pliki, nie zamykając ich. Zachowaj obserwowane wartości i fragmenty logów: posłużą do decyzji, czy limit był zbyt niski, czy usługa wymaga poprawy.