Atopar o límite real de descritores de ficheiro do Squid
Lea os límites do proceso do proxy en execución antes de cambiar a configuración de PAM ou copiar un valor nofile fixo dunha receita de capacidade.
Inspeccione o daemon en execución antes de confiar en ulimit -n da shell de inicio de sesión. Para unha instalación que usa squid.service, comece con:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLea /proc/PID/limits co identificador real do proceso. Nun despregamento multiproceso, comprobe tamén o traballador correspondente. Un valor gardado na configuración non demostra que este proceso o herdase.
| Control | Alcance |
|---|---|
Shell ulimit e PAM limits.conf | Os descendentes da shell ou as sesións que realmente usan o axuste de PAM |
systemd LimitNOFILE= | Procesos iniciados baixo a política de recursos dese servizo |
Squid max_filedescriptors, onde é compatible | Límite da aplicación dentro das restricións do sistema operativo |
Un servizo do sistema non adopta os cambios de PAM só porque un administrador modificase o ficheiro. Use un drop-in específico do servizo cando corresponda cambiar o seu límite de systemd. Squid documenta que max_filedescriptors require reiniciar para cambiar; se se deixa sen definir, herda o límite brando do sistema operativo.
Dimensione o límite por descritores, non por usuarios. Os clientes poden manter varios sockets, e as conexións saíntes, os rexistros e as canles auxiliares tamén consomen descritores. Subir o límite permite máis consumo sen reservar de inmediato unha cantidade fixa de RAM por cada descritor posible. Nin unha vella estimación de memoria por socket nin 65,535 son un requisito universal de capacidade ou un teito de Linux.
Tras o cambio do servizo, compare os límites do novo proceso cos valores previstos. Se aparecen fallos moi por baixo deles, investigue o recurso que realmente se esgota.