zrozumienie maksymalnej liczby deskryptorów plików dla Linuksa i Nginxa oraz najlepszej wartości dla pliku_profilu_rlimit


10

Na nginx pojawia się pozornie powszechny błąd „zbyt wielu deskryptorów plików”. Po wielu poszukiwaniach rozwiązaniem jest wyraźnie zwiększenie liczby deskryptorów plików dostępnych dla nginx. Ale nie ma wystarczająco dużo informacji, aby czuć się komfortowo, robiąc to w znaczący i bezpieczny sposób. Oto główne punkty, które obejmują większość wątków na forum / w e-mailu:

  • system operacyjny ma swój własny całkowity limit deskryptorów plików (w moim systemie cat /proc/sys/fs/file-maxwyniki „100678”)
  • każdy użytkownik może mieć również swój własny limit (ale w moim systemie, działający ulimitjak każdy użytkownik wyświetla „nieograniczony”, patrz aktualizacja u dołu ze szczegółami )
  • kilka osób powiedziało coś podobnego do tego, co powiedziała ta osoba : „Dyrektywa pracownik_rlimit_nofile nie określa„ ile ”, to limit systemu operacyjnego, który to robi. Dyrektywa worker_rlimit_nofile pozwala tylko na szybki i brudny sposób na zwiększenie tego limitu, jeśli to nie wystarczy ”. Sądzę więc, że implikacją jest to, że „lepiej” ustawić limit dla użytkownika systemu operacyjnego Nginx zamiast w konfiguracji?

Mogę po prostu podać wartość parametru robot_rlimit_nofile większą niż liczba połączeń na pracownika i nazwać go dniem, ale wydaje mi się, że tak naprawdę nie wiem, co się tutaj dzieje.

  • dlaczego limit na pracownika byłby mniejszy niż limit systemu operacyjnego?
  • Jak dowiedzieć się, jaki jest teraz mój limit?

aktualizacja : zarówno dla użytkownika root, jak i zwykłego użytkownika, ulimit wyprowadza „nieograniczony”, ALE ulimit -Hni ulimit -Snoba wyprowadza 1024

Odpowiedzi:


10

worker_rlimit_nofileustawi limit deskryptorów plików dla procesów roboczych w przeciwieństwie do użytkownika uruchamiającego nginx. Jeśli inne programy działające pod tym użytkownikiem nie będą w stanie z wdziękiem poradzić sobie z brakiem opisów plików, należy ustawić ten limit nieco mniej niż to, co jest dla użytkownika.

Po pierwsze, do czego służą deskryptory plików?

  1. Każde aktywne połączenie z klientem
  2. Używasz proxy_pass? Otworzy to gniazdo hosta: port obsługujący te żądania
  3. Używasz proxy_pass do portu lokalnego? To kolejne otwarte gniazdo. (Dla właściciela tego procesu)
  4. pliki statyczne są obsługiwane przez nginx

Dlaczego limit na pracownika byłby mniejszy niż limit systemu operacyjnego?

Jest to kontrolowane przez system operacyjny, ponieważ pracownik nie jest jedynym procesem uruchomionym na komputerze. Aby to zmienić dla użytkownika uruchamiającego nginx, patrz poniżej. Byłoby bardzo źle, gdyby twoi pracownicy zużyli wszystkie deskryptory plików dostępne dla wszystkich procesów, nie ustalaj swoich limitów, aby było to możliwe.

#/etc/sysctl.conf
#This sets the value you see when running cat  /proc/sys/fs/file-max
fs.file-max = 65536"


#/etc/security/limits.conf
#this sets the defaults for all users
* soft nofile 4096
* hard nofile 4096

#This overrides the default for user `usernamehere`
usernamehere soft nofile 10240
usernamehere hard nofile 10240

Po tych zmianach limitów bezpieczeństwa nadal uważam, że musiałem zwiększyć limit miękki dla użytkownika ulimit.

Jak dowiedzieć się, jaki jest teraz mój limit?

ulimit -a Wyświetli wszystkie limity związane z użytkownikiem, który go uruchamiasz.


1
Dzięki - teraz, gdy podniosłem limit deskryptorów plików, kończą mi się połączenia. Może ty też możesz mi w tym pomóc :) serverfault.com/questions/209014/…
John Bachir

1
Uwaga dla użytkowników CentOS / Fedora, jeśli masz włączony SELinux, będziesz musiał uruchomić setsebool -P httpd_setrlimit 1, aby nginx miał uprawnienia do ustawienia swojego ograniczenia.
Jarrett,

2

Muszę sprawdzić źródło, aby być szczerym, ale jest dość niskie.

Użyłem worker_rlimit_nofile 15000;i nie miałem problemów, możesz go bezpiecznie zwiększyć, jednak szansa na wyczerpanie deskryptorów plików jest znikoma.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.