Zistenie skutočného limitu deskriptorov súborov Squida
Prečítajte si limity procesu bežiaceho proxy skôr, než zmeníte nastavenia PAM alebo skopírujete pevnú hodnotu nofile z receptu na kapacitu.
Preskúmajte bežiaceho démona, než uveríte ulimit -n prihlasovacieho shellu. Pri inštalácii, ktorá používa squid.service, začnite takto:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.servicePrečítajte /proc/PID/limits so skutočným ID procesu. V nasadení s viacerými procesmi skontrolujte aj príslušný worker. Hodnota uložená v konfigurácii nie je dôkazom, že tento proces ju zdedil.
| Riadenie | Rozsah |
|---|---|
Shell ulimit a PAM limits.conf | Potomkovia shellu alebo relácie, ktoré nastavenie PAM skutočne používajú |
systemd LimitNOFILE= | Procesy spustené podľa pravidiel prostriedkov tejto služby |
Squid max_filedescriptors, ak je podporované | Limit aplikácie v rámci obmedzení operačného systému |
Systémová služba nepreberá úpravy PAM len preto, že administrátor zmenil súbor. Keď je zmena jej limitu systemd vhodná, použite drop-in špecifický pre službu. Squid dokumentuje, že max_filedescriptors vyžaduje na zmenu reštart; ak zostane nenastavený, dedí mäkký limit operačného systému.
Dimenzujte limit podľa deskriptorov, nie podľa používateľov. Klienti môžu držať viac socketov, a aj odchádzajúce spojenia, záznamy a pomocné rúry spotrebúvajú deskriptory. Zvýšenie limitu umožňuje väčšiu spotrebu bez okamžitého rezervovania pevného množstva RAM na každý možný deskriptor. Univerzálnou požiadavkou na kapacitu ani stropom Linuxu nie je ani starý odhad pamäte na socket, ani 65,535.
Po zmene služby porovnajte limity nového procesu so zamýšľanými hodnotami. Ak sa chyby vyskytujú výrazne pod nimi, skúmajte prostriedok, ktorý sa skutočne vyčerpáva.