De echte bestandsdescriptorgrens van Squid vinden
Lees de proceslimieten van de draaiende proxy voordat u PAM-instellingen wijzigt of een vaste nofile-waarde uit een capaciteitsrecept kopieert.
Inspecteer de draaiende daemon voordat u de ulimit -n van de login-shell vertrouwt. Voor een installatie die squid.service gebruikt, begint u met:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLees /proc/PID/limits met het werkelijke proces-ID. Controleer bij een implementatie met meerdere processen ook de betreffende worker. Een waarde die in de configuratie is opgeslagen, bewijst niet dat dit proces die heeft geërfd.
| Beheer | Bereik |
|---|---|
Shell ulimit en PAM limits.conf | De nakomelingen van de shell of sessies die de PAM-instelling daadwerkelijk gebruiken |
systemd LimitNOFILE= | Processen die zijn gestart onder het resourcebeleid van die service |
Squid max_filedescriptors, waar ondersteund | Applicatielimiet binnen de beperkingen van het besturingssysteem |
Een systeemservice neemt PAM-wijzigingen niet over alleen omdat een beheerder het bestand heeft gewijzigd. Gebruik een servicespecifieke drop-in wanneer het wijzigen van de systemd-limiet gepast is. Squid documenteert dat max_filedescriptors een herstart vereist om te wijzigen; blijft die oningesteld, dan wordt de zachte limiet van het besturingssysteem geërfd.
Bereken de limiet op descriptors, niet op gebruikers. Clients kunnen meerdere sockets vasthouden, en ook uitgaande verbindingen, logboeken en hulppipes verbruiken descriptors. De limiet verhogen staat meer verbruik toe zonder meteen een vaste hoeveelheid RAM per mogelijke descriptor te reserveren. Noch een oude schatting van geheugen per socket noch 65,535 is een universele capaciteitseis of een Linux-plafond.
Vergelijk na de servicewijziging de limieten van het nieuwe proces met de bedoelde waarden. Als er fouten optreden ver onder die waarden, onderzoek dan de resource die werkelijk uitgeput raakt.