Descobrir o limite real de descritores de arquivo do Squid
Leia os limites de processo do proxy em execução antes de alterar configurações do PAM ou copiar um valor nofile fixo de uma receita de capacidade.
Inspecione o daemon em execução antes de confiar no ulimit -n do shell de login. Para uma instalação que usa squid.service, comece com:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLeia /proc/PID/limits usando o ID real do processo. Numa implantação multiprocesso, verifique também o worker correspondente. Um valor guardado na configuração não prova que este processo o herdou.
| Controle | Âmbito |
|---|---|
Shell ulimit e PAM limits.conf | Os descendentes do shell ou as sessões que realmente usam a configuração do PAM |
systemd LimitNOFILE= | Processos iniciados sob a política de recursos desse serviço |
Squid max_filedescriptors, onde é suportado | Limite da aplicação dentro das restrições do sistema operativo |
Um serviço de sistema não adota alterações do PAM só porque um administrador mudou o ficheiro. Use um drop-in específico do serviço quando for apropriado alterar o seu limite systemd. O Squid documenta que max_filedescriptors exige reinício para mudar; se ficar por definir, herda o limite suave do sistema operativo.
Dimensione o limite por descritores, não por utilizadores. Os clientes podem manter vários sockets, e as ligações de saída, os registos e os pipes auxiliares também consomem descritores. Aumentar o limite permite mais consumo sem reservar logo uma quantidade fixa de RAM por cada descritor possível. Nem uma antiga estimativa de memória por socket nem 65,535 são um requisito universal de capacidade ou um teto do Linux.
Depois da alteração do serviço, compare os limites do novo processo com os valores pretendidos. Se ocorrerem falhas muito abaixo deles, investigue o recurso que está realmente a esgotar-se.