시간이 지나면서 느려지는 프록시: conntrack과 리소스 한도 점검

프록시는 재시작 직후에는 응답한다. 몇 시간 뒤 새 연결이 멈춘다. 다시 재시작하면 또 한 번 조용한 구간을 산다. 이 패턴은 상태가 누적되고 있음을 시사하지만, 어떤 상태가 원인인지는 알려주지 않는다.

연결 추적을 사용하는 Linux 경로에서는 conntrack 테이블이 후보 중 하나다. 머신과 트래픽을 처리하는 네트워크 네임스페이스에서 다음 기존 값을 확인한다:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

첫 번째는 할당된 플로 항목을 보고하고, 두 번째는 그 한도를 정한다. 이것은 Squid 사용자 수나 HTTP 요청 수가 아니다. 커널의 플로 상태는 애플리케이션의 활성 작업보다 오래 살아남을 수 있다.

큰 숫자만이 아니라 관계를 보라

시간에 따른 점유율을 새 연결 실패의 시작과 관련 커널 메시지에 견주어 본다. 대응하는 장애 증거가 없는 높은 수치는 요청이 시간 초과되기 시작하는 바로 그때 여러 번 한도에 도달하는 테이블과는 다르다.

테이블은 프록시 외의 용도로도 쓰일 수 있다. 다른 로컬 서비스, 전달되는 트래픽, 또는 다른 바쁜 네트워크 경로가 기여할 수 있다. 프록시를 재시작했을 때 증상이 달라진다고 해서 Squid의 객체 캐시가 원인이었다는 증명은 아니다.

경쟁하는 설명들을 시야에 두라: 파일 디스크립터, 인증 헬퍼 큐, DNS 지연, 메모리 압박, 가득 찬 파일 시스템도 시간이 지나면서 악화될 수 있다. 어떤 리소스가 늘고 어떤 작업이 먼저 작동을 멈추는지 기록하라. 오래 사는 연결이 살아남고 새 연결이 실패하는 것은 유용한 증거이지 그 자체로 진단은 아니다.

한도를 올리는 데는 메모리 비용이 든다. 바꾸기 전에 워크로드, 네임스페이스, 사용 가능한 용량을 확정하라. 시간 제한을 무분별하게 줄이면 유용한 유휴 세션이 깨질 수 있고, 모든 연결 상태를 비우면 무관한 트래픽이 방해받을 수 있다.

유용한 결과는 누적에 대한 설명과 그에 맞는 용량 또는 수명 주기 변경이다. 안전하게 올릴 수 있다는 것은 모든 프록시 서버가 공유하는 속성이 아니다.