A Squid valódi fájlleíró-korlátjának megállapítása
Olvassa ki a futó proxy folyamatkorlátait, mielőtt módosítaná a PAM-beállításokat vagy átmásolna egy rögzített nofile-értéket egy kapacitás-receptből.
Vizsgálja meg a futó démont, mielőtt megbízna a bejelentkező shell ulimit -n értékében. A squid.service szolgáltatást használó telepítésnél ezzel kezdje:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceOlvassa ki a /proc/PID/limits fájlt a tényleges folyamatazonosítóval. Többfolyamatos telepítésnél a megfelelő workert is ellenőrizze. A konfigurációban mentett érték nem bizonyítja, hogy ez a folyamat örökölte.
| Vezérlés | Hatókör |
|---|---|
Shell ulimit és PAM limits.conf | A shell leszármazottai vagy azok a munkamenetek, amelyek ténylegesen használják a PAM-beállítást |
systemd LimitNOFILE= | A szolgáltatás erőforrás-szabályzata alatt indított folyamatok |
Squid max_filedescriptors, ahol támogatott | Az alkalmazás korlátja az operációs rendszer megszorításain belül |
Egy rendszerszolgáltatás nem veszi át a PAM-módosításokat csak azért, mert a rendszergazda megváltoztatta a fájlt. Használjon szolgáltatásspecifikus drop-int, amikor a systemd-korlát módosítása indokolt. A Squid dokumentálja, hogy a max_filedescriptors módosításához újraindítás kell; beállítatlanul hagyva az OS lágy korlátját örökli.
A korlátot leírókra, ne felhasználókra méretezze. Az ügyfelek több socketet is tarthatnak, és a kimenő kapcsolatok, a naplók és a segédcsövek is fogyasztanak leírókat. A korlát emelése több fogyasztást tesz lehetővé anélkül, hogy azonnal rögzített RAM-mennyiséget foglalna minden lehetséges leíróhoz. Sem egy régi, socketenkénti memóriabecslés, sem a 65,535 nem általános kapacitáskövetelmény vagy Linux-plafon.
A szolgáltatás módosítása után hasonlítsa össze az új folyamat korlátait a tervezett értékekkel. Ha a hibák jóval ezek alatt jelentkeznek, vizsgálja meg a ténylegesen kimerülő erőforrást.