Encontrar el límite real de descriptores de archivo de Squid
Lea los límites del proceso del proxy en ejecución antes de cambiar la configuración de PAM o copiar un valor nofile fijo de una receta de capacidad.
Inspeccione el demonio en ejecución antes de confiar en ulimit -n del shell de inicio de sesión. Para una instalación que usa squid.service, empiece con:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLea /proc/PID/limits con el identificador real del proceso. En un despliegue multiproceso, compruebe también el trabajador correspondiente. Un valor guardado en la configuración no demuestra que este proceso lo haya heredado.
| Control | Alcance |
|---|---|
Shell ulimit y PAM limits.conf | Los descendientes del shell o las sesiones que realmente usan el ajuste de PAM |
systemd LimitNOFILE= | Procesos iniciados bajo la política de recursos de ese servicio |
Squid max_filedescriptors, cuando es compatible | Límite de la aplicación dentro de las restricciones del sistema operativo |
Un servicio del sistema no adopta los cambios de PAM solo porque un administrador haya modificado el archivo. Use un drop-in específico del servicio cuando corresponda cambiar su límite de systemd. Squid documenta que max_filedescriptors requiere reiniciar para cambiar; si se deja sin definir, hereda el límite blando del sistema operativo.
Dimensione el límite por descriptores, no por usuarios. Los clientes pueden mantener varios sockets, y las conexiones salientes, los registros y las tuberías auxiliares también consumen descriptores. Subir el límite permite más consumo sin reservar de inmediato una cantidad fija de RAM por cada descriptor posible. Ni una vieja estimación de memoria por socket ni 65,535 son un requisito universal de capacidad ni un techo de Linux.
Tras el cambio del servicio, compare los límites del nuevo proceso con los valores previstos. Si hay fallos muy por debajo de ellos, investigue el recurso que realmente se agota.