Ustalenie rzeczywistego limitu deskryptorów plików Squida
Odczytaj limity procesu działającego proxy, zanim zmienisz ustawienia PAM lub skopiujesz stałą wartość nofile z przepisu na wydajność.
Zbadaj działającego demona, zanim zaufasz ulimit -n powłoki logowania. W instalacji używającej squid.service zacznij od:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceOdczytaj /proc/PID/limits, używając rzeczywistego identyfikatora procesu. We wdrożeniu wieloprocesowym sprawdź także odpowiedniego workera. Wartość zapisana w konfiguracji nie dowodzi, że ten proces ją odziedziczył.
| Kontrola | Zakres |
|---|---|
Powłoka ulimit i PAM limits.conf | Potomkowie powłoki lub sesje, które faktycznie korzystają z ustawienia PAM |
systemd LimitNOFILE= | Procesy uruchomione w ramach polityki zasobów tej usługi |
Squid max_filedescriptors, jeśli jest obsługiwane | Limit aplikacji w granicach ograniczeń systemu operacyjnego |
Usługa systemowa nie przejmuje zmian PAM tylko dlatego, że administrator zmienił plik. Użyj drop-inu specyficznego dla usługi, gdy zmiana jej limitu systemd jest właściwa. Squid dokumentuje, że max_filedescriptors wymaga ponownego uruchomienia, aby się zmienić; pozostawiony bez ustawienia dziedziczy miękki limit systemu.
Wymiaruj limit pod deskryptory, a nie pod użytkowników. Klienci mogą trzymać wiele gniazd, a połączenia wychodzące, logi i potoki pomocnicze również zużywają deskryptory. Podniesienie limitu pozwala na większe zużycie bez natychmiastowego rezerwowania stałej ilości RAM na każdy możliwy deskryptor. Ani stary szacunek pamięci na gniazdo, ani 65,535 nie są uniwersalnym wymaganiem wydajnościowym ani pułapem Linuksa.
Po zmianie usługi porównaj limity nowego procesu z zamierzonymi wartościami. Jeśli błędy pojawiają się znacznie poniżej nich, zbadaj zasób, który faktycznie się wyczerpuje.