접속 지연의 원인: ulimit

· 운영Linux트러블슈팅

공개 가능한 형태로 익명화한 운영 기록.

트래픽이 늘어나는 구간에서 WEB·WAS가 간헐적으로 응답 지연·연결 실패를 냈다. CPU·메모리는 여유가 있어서 사양 문제로는 안 보였다.

먼저 한도부터 봤다.

ulimit -n            # open files
ulimit -u            # max user processes
ls /proc/<pid>/fd | wc -l    # 프로세스가 실제로 연 fd 수
grep -i "too many open files" catalina.out

WAS 로그에 Too many open files가 찍혀 있었다. 동시 연결이 많은 서버인데 기본 nofile이 1024~4096이라, 파일 디스크립터가 고갈돼서 신규 연결이 실패한 거였다.

임시로 올려보고,

ulimit -n 65536

영구 설정은 limits.conf에 박았다.

* soft nofile 65536
* hard nofile 65536
* soft nproc  10240
* hard nproc  10240

systemd로 뜨는 서비스면 유닛에도 LimitNOFILE=65536을 줘야 반영된다.

메모리 buff/cache가 쌓여 압박이 의심될 때 수동으로 비우고, cron으로 주기적으로 비우는 것도 해봤다.

sync; echo 3 > /proc/sys/vm/drop_caches

근데 솔직히 drop_caches는 근본 해결이 아니다. 페이지 캐시는 원래 커널이 필요할 때 알아서 회수하고, 무분별하게 주기적으로 비우면 오히려 캐시 적중률이 떨어져서 성능에 안 좋을 수 있다. 실제 누수나 특수한 상황에서 임시 완화책으로만 쓰고, 근본은 앱·JVM 쪽에서 따로 봐야 한다.

정리하면, 사양을 키우기 전에 OS 한도부터 본다. 동시 연결 많은 서버는 nofile이 1순위 점검 대상이었다. 다음엔 신규 서버 셋업할 때 limits부터 박아두려고 한다.

예전 블로그에 적었던 작업 기록을 옮겨온 글입니다.

← Blog 목록