Linux 서버를 운영하다 보면 웹 서버, 데이터베이스, Java 애플리케이션, Docker, Kubernetes 환경에서 Too many open files, EMFILE, errno 24와 같은 오류를 자주 볼 수 있습니다. 이 오류는 프로세스가 사용할 수 있는 파일 디스크립터(File Descriptor, FD)의 한도를 초과했을 때 발생하는 대표적인 시스템 오류입니다.

이 오류가 발생하면 새로운 파일을 열거나 네트워크 연결을 생성할 수 없으며, 심한 경우 서비스가 정상적으로 동작하지 않을 수 있습니다.

이번 글에서는 Too Many Open Files 오류의 원인과 확인 방법, 해결 방법 및 실무에서 자주 사용하는 점검 절차를 자세히 알아보겠습니다.

Too Many Open Files란?

Linux에서는 파일뿐만 아니라 다음과 같은 자원도 모두 파일 디스크립터(FD)를 사용합니다.

일반 파일
TCP Socket
UDP Socket
Pipe
FIFO
Device File
EventFD
Inotify

즉, 네트워크 연결이 많아져도 FD를 계속 사용하게 됩니다.

오류 예시는 다음과 같습니다.

Too many open files

EMFILE

errno=24

이는 현재 프로세스가 더 이상 사용할 수 있는 FD가 없다는 의미입니다.

Too Many Open Files가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

파일 디스크립터 제한값이 낮음
Socket Leak
CLOSE_WAIT 증가
로그 파일 미정리
애플리케이션 버그
Connection Pool 오류
대량의 TCP 연결
Inotify 과다 사용
Docker 컨테이너 증가
Kubernetes Pod 증가

실무에서는 애플리케이션이 FD를 해제하지 못하는 경우가 가장 많습니다.

1. 현재 FD 제한 확인하기

현재 Shell의 제한값을 확인합니다.

ulimit -n

예시

1024는 운영 서버에서는 다소 낮은 값일 수 있습니다.

2. 시스템 전체 제한 확인하기

시스템 전체 설정을 확인합니다.

cat /proc/sys/fs/file-max

예시

9223372036854775807

이 값은 시스템 전체에서 사용할 수 있는 최대 FD 개수입니다.

3. 현재 사용 중인 FD 확인하기

전체 사용량을 확인합니다.

cat /proc/sys/fs/file-nr

예시

8500    0    1048576

각 값의 의미는 다음과 같습니다.

현재 사용 중인 FD
사용되지 않는 FD
최대 FD

4. 프로세스별 FD 확인하기

PID가 1234인 경우

ls /proc/1234/fd | wc -l

또는

lsof -p 1234

특정 프로세스가 비정상적으로 많은 FD를 사용하는지 확인합니다.

5. FD를 많이 사용하는 프로세스 찾기

다음 명령으로 확인할 수 있습니다.

lsof | awk '{print $2}' | sort | uniq -c | sort -nr | head

가장 많은 FD를 사용하는 프로세스를 우선 분석합니다.

6. Soft Limit와 Hard Limit 확인하기

현재 Limit를 확인합니다.

ulimit -Sn

ulimit -Hn

예시

Soft : 1024
Hard : 65535

Soft Limit은 Hard Limit 이하에서 자유롭게 변경할 수 있습니다.

7. Limit 늘리기

현재 세션에서 증가시키려면

ulimit -n 65535

영구 적용하려면

/etc/security/limits.conf

예시

* soft nofile 65535
* hard nofile 65535

PAM을 사용하는 환경에서는 재로그인 후 적용됩니다.

8. systemd 서비스 확인하기

systemd에서는 별도로 설정해야 하는 경우가 많습니다.

서비스 설정 파일에 다음을 추가합니다.

LimitNOFILE=65535

설정 후 적용합니다.

systemctl daemon-reload

systemctl restart 서비스명

9. CLOSE_WAIT 확인하기

FD 누수는 CLOSE_WAIT 증가와 함께 발생하는 경우가 많습니다.

ss -ant | grep CLOSE-WAIT | wc -l

CLOSE_WAIT가 많다면 애플리케이션이 Socket을 닫지 못하고 있을 가능성이 높습니다.

10. 애플리케이션 로그 확인하기

로그에서 관련 오류를 확인합니다.

Nginx

journalctl -u nginx

Tomcat

journalctl -u tomcat

Java 환경에서는 다음과 같은 오류가 나타날 수 있습니다.

java.io.IOException:
Too many open files

Too Many Open Files 점검 순서

실무에서는 다음 순서대로 점검하는 것이 좋습니다.

ulimit 확인
file-max 확인
file-nr 확인
프로세스별 FD 확인
FD 사용량 분석
Soft/Hard Limit 확인
Limit 증가
systemd 설정 확인
CLOSE_WAIT 확인
애플리케이션 로그 분석

Too Many Open Files 사용 시 주의사항

다음 사항을 고려해야 합니다.

무조건 Limit만 늘리지 않는다.
FD Leak 여부를 먼저 확인한다.
CLOSE_WAIT도 함께 분석한다.
Connection Pool 설정을 확인한다.
systemd 설정도 변경해야 한다.
애플리케이션의 Socket close() 호출을 점검한다.

단순히 FD 제한을 늘리는 것은 임시 해결책이며, FD 누수의 원인을 찾는 것이 가장 중요합니다.

Too Many Open Files와 Out of Memory의 차이

항목	Too Many Open Files	Out of Memory
원인	FD 부족	메모리 부족
주요 자원	File Descriptor	RAM
오류 코드	EMFILE	OOM
해결 방법	FD 관리 및 Limit 조정	메모리 증설 및 최적화

두 오류는 모두 시스템 자원 부족과 관련 있지만 원인이 다르므로 구분해서 대응해야 합니다.

자주 묻는 질문

ulimit만 늘리면 문제가 해결되나요?

아닙니다. FD 누수가 있다면 시간이 지나 다시 같은 문제가 발생합니다. 먼저 어떤 프로세스가 FD를 과도하게 사용하는지 확인해야 합니다.

운영 서버에서는 FD를 얼마로 설정하는 것이 좋나요?

환경에 따라 다르지만 일반적인 웹 서버에서는 65535 이상을 사용하는 경우가 많습니다. 대규모 서비스에서는 더 높은 값을 설정하기도 합니다.

CLOSE_WAIT와 Too Many Open Files는 관련이 있나요?

네. CLOSE_WAIT가 계속 증가하면 Socket이 닫히지 않아 FD가 해제되지 않고, 결국 Too Many Open Files 오류로 이어질 수 있습니다.

마무리

Too Many Open Files(EMFILE)는 파일 디스크립터 한도를 초과했을 때 발생하는 대표적인 Linux 시스템 오류입니다. ulimit, lsof, /proc, ss 등을 활용하면 FD 사용 현황과 누수 여부를 빠르게 확인할 수 있으며, FD 제한 조정과 함께 애플리케이션의 Socket 관리 로직을 개선하면 안정적인 서버 운영에 큰 도움이 됩니다.

Linux Too Many Open Files 오류의 원인과 해결 방법