Squid se werklike lêerbeskrywer-limiet vind
Lees die lopende proxy se proseslimiete voordat jy PAM-instellings verander of 'n vaste nofile-waarde uit 'n kapasiteitsresep kopieer.
Ondersoek die lopende daemon voordat jy die aanmeldskulp se ulimit -n vertrou. Vir 'n installasie wat squid.service gebruik, begin met:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLees /proc/PID/limits met die werklike proses-ID. In 'n multproses-ontplooiing, kyk ook na die betrokke werker. 'n Waarde wat in die konfigurasie gestoor is, is nie bewys dat hierdie proses dit geërf het nie.
| Beheer | Omvang |
|---|---|
Skulp ulimit en PAM limits.conf | Die skulp se nasate of sessies wat werklik die PAM-instelling gebruik |
systemd LimitNOFILE= | Prosesse wat onder daardie diens se hulpbronbeleid begin is |
Squid max_filedescriptors, waar ondersteun | Toepassingslimiet binne die bedryfstelsel se beperkings |
'n Stelseldiens neem nie PAM-wysigings oor net omdat 'n administrateur die lêer verander het nie. Gebruik 'n diensspesifieke drop-in wanneer dit gepas is om sy systemd-limiet te verander. Squid dokumenteer dat max_filedescriptors 'n herbegin vereis om te verander; as dit ongestel gelaat word, erf dit die OS se sagte limiet.
Maak die limiet groot genoeg vir lêerbeskrywers, nie vir gebruikers nie. Kliënte kan verskeie sokkels hou, en verdere verbindings, logboeke en hulppype verbruik ook lêerbeskrywers. Om die limiet te verhoog laat meer verbruik toe sonder om dadelik 'n vaste hoeveelheid RAM per moontlike lêerbeskrywer te reserveer. Nie 'n ou skatting van geheue per sokkel nie, en ook nie 65,535 nie, is 'n universele kapasiteitsvereiste of Linux-plafon.
Vergelyk ná die diensverandering die nuwe proses se limiete met die beoogde waardes. As foute veel onder hulle voorkom, ondersoek die hulpbron wat werklik uitgeput word.