Linux: Too many open files (EMFILE)

안녕하세요, BlueByte입니다. 부하가 걸릴 때 서비스가 EMFILE을 던지기 시작하면, 사실 한 오류 안에 질문이 둘 숨어 있습니다 — 한도가 낮은 건가, 아니면 뭔가 새는 건가. 오늘은 이 둘부터 가른 뒤 — 한도 올림은 하나만 고치고 다른 하나는 미루기만 하니까 — 프로세스가 실제로 도는 곳에 해결을 적용하는 순서로 가보겠습니다.

EMFILE이 알려주는 것

부하가 걸리면 서버나 스크립트가 실패하기 시작합니다:

Error: EMFILE: too many open files

프로세스가 허용된 파일 디스크립터 최대치를 넘겨 파일·소켓·연결을 열려고 했습니다. 소켓과 파이프도 모두 세므로, 바쁜 네트워크 서비스는 실제 파일이 바닥나기 한참 전에 걸립니다. 실패는 프로세스 단위이고, 해결은 그 프로세스가 실제로 도는 곳에 적용해야 합니다 — 사람들이 가장 자주 틀리는 지점입니다.

한도가 낮은가, 새는가 — 두 진짜 원인

각 프로세스에는 열린 디스크립터의 소프트 한도가 있습니다(기본 1024인 경우 많음). 도달하면 모든 새 open()·socket()·accept()가 EMFILE로 실패합니다. 근본 상황은 둘이고 대응이 다릅니다:

• 한도가 정말 낮음 — 수천 동시 연결을 다루는 프록시·DB는 1024보다 훨씬 필요.
• 프로세스가 디스크립터를 누수 — 닫지 않는 연결·파일을 계속 열어 수가 천장까지 늘기만 함.

이 둘을 가르는 게 전부입니다.

디스크립터 수를 지켜보며 둘을 가르기

어느 쪽인지 추측할 필요 없습니다 — 지켜보면 됩니다. 현재 한도와 프로세스가 지금 쥔 개수를 확인:

ulimit -n
ls /proc/$(pgrep -f myservice)/fd | wc -l

그 둘째 수를 몇 분간 일정한 트래픽에서 지켜보세요. 오르기만 하고 안 떨어지면 누수, 실제 부하에서 한도 근처에 머물면 한도가 낮은 것입니다. 셸이 아니라 실행 중 프로세스의 실효 한도를 보려면:

grep "open files" /proc/$(pgrep -f myservice)/limits

프로세스가 도는 곳에서 한도를 올리기

1. 서비스면 도는 곳에서 한도를 올립니다. systemd 유닛은 셸 ulimit을 무시하므로 유닛에 설정:

# /etc/systemd/system/myservice.service
[Service]
LimitNOFILE=65536

sudo systemctl daemon-reload
sudo systemctl restart myservice

2. 로그인 세션이면 /etc/security/limits.conf에 추가 후 새 세션을 엽니다:

*  soft  nofile  65536
*  hard  nofile  65536

3. 누수를 찾았으면 열고 안 닫는 코드를 고치세요 — 한도 올림은 시간만 벌 뿐입니다.

실제 사례: 낮은 한도가 아니라 누수

Node 서비스가 트래픽 약 1시간 뒤 EMFILE을 던지기 시작합니다. ls /proc/<pid>/fd | wc -l이 1024에 고정돼 있고, 이전 실행에서 10분간 지켜봤을 때 꾸준히 오르기만 하고 안 떨어졌습니다. 낮은 한도가 아니라 누수 지문입니다 — 앱이 요청마다 HTTP 클라이언트를 열고 안 닫습니다. 클라이언트가 풀링된 연결을 재사용하도록 고치니 같은 부하에서 디스크립터 수가 약 200에 머뭅니다. 여유로 LimitNOFILE을 65536으로 올리긴 하지만, 실패를 실제로 멈춘 건 누수 수정입니다.

한도가 셸이 아니라 프로세스에 적용됐는지 확인

사람들이 건너뛰는 단계이니 직접 확인하세요:

cat /proc/$(pgrep -f myservice)/limits | grep "open files"

"Max open files" 열에 설정 값이 보여야 합니다. 그다음 실패하던 부하를 돌려 더는 실패하지 않고 디스크립터 수가 안정적인지 확인하세요.

다시 겪지 않으려면

네트워크 서비스는 유닛 파일에 LimitNOFILE을 의도적으로 두고 실제 동시성 + 여유에 맞추며, 디스크립터 수에 메트릭·알림을 걸어 느린 누수가 서비스를 죽이기 훨씬 전에 보이게 하세요.

ENFILE과의 구분

EMFILE은 프로세스 단위, ENFILE("file table overflow")은 시스템 전체 소진 — 훨씬 드물고 커널 전역 fs.file-max sysctl로 고칩니다. 셸에서 ulimit 작업 중 나는 "Too many open files"는 같은 한도지만 대화식으로 도달한 것입니다. EMFILE을 만나면 무언가 올리기 전에 수를 지켜보세요 — 그래프가 어느 문제인지 알려줍니다.