Squid의 실제 파일 디스크립터 한계 찾기
PAM 설정을 바꾸거나 용량 레시피에서 고정된 nofile 값을 복사하기 전에 실행 중인 프록시의 프로세스 한도를 읽으세요.
로그인 셸의 ulimit -n 을 믿기 전에 실행 중인 데몬을 검사하세요. squid.service 을 사용하는 설치라면 다음으로 시작하세요.
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service실제 프로세스 ID로 /proc/PID/limits 을 읽으세요. 다중 프로세스 배포에서는 해당 워커도 확인하세요. 설정 파일에 저장된 값은 이 프로세스가 그 값을 상속받았다는 증거가 아닙니다.
| 제어 | 범위 |
|---|---|
셸 ulimit 및 PAM limits.conf | 셸의 자손 또는 PAM 설정을 실제로 사용하는 세션 |
systemd LimitNOFILE= | 해당 서비스의 리소스 정책 아래에서 시작된 프로세스 |
Squid max_filedescriptors(지원되는 경우) | 운영 체제 제약 안에서의 애플리케이션 한도 |
관리자가 파일을 바꿨다는 이유만으로 시스템 서비스가 PAM 수정을 받아들이지는 않습니다. systemd 한도를 바꾸는 것이 적절할 때는 서비스 전용 drop-in을 사용하세요. Squid 문서에 따르면 max_filedescriptors 은 변경하려면 재시작이 필요합니다. 설정하지 않으면 OS의 소프트 한도를 상속합니다.
한도는 사용자 수가 아니라 디스크립터 수로 산정하세요. 클라이언트는 여러 소켓을 보유할 수 있고, 외부 연결, 로그, 헬퍼 파이프도 디스크립터를 소비합니다. 한도를 올리면 가능한 모든 디스크립터마다 고정된 RAM을 즉시 예약하지 않고도 더 많은 소비를 허용합니다. 소켓당 메모리에 대한 옛 추정치도 65,535도 보편적인 용량 요구나 Linux의 상한이 아닙니다.
서비스를 변경한 뒤 새 프로세스의 한도를 의도한 값과 비교하세요. 그보다 훨씬 낮은 지점에서 실패가 발생하면 실제로 고갈되는 리소스를 조사하세요.