여기서는 멈추세요
- FD 수가 빠르게 계속 증가하면 limit 상향만으로 해결하지 않고 애플리케이션 누수 조사를 시작합니다.
- 서비스 재시작의 트래픽 영향과 롤백 창을 확보하지 못하면 override를 적용하지 않습니다.
FILE DESCRIPTORS
Too many open files 오류가 발생할 때
프로세스의 실제 파일 디스크립터 사용량과 soft·hard limit을 비교해 누수와 단순 제한 부족을 구분합니다.Too many open filesEMFILELimitNOFILEfile descriptor leakulimit -n
환경Ubuntu 22.04·24.04 LTS · Linux procfs · systemd service
분류CPU·메모리
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
systemctl edit로 추가한 정확한 LimitNOFILE 줄을 제거하고 daemon-reload·승인된 재시작 후 이전 limit이 복원됐는지 확인합니다.
담당자에게 전달할 자료
- 오류 시각의 PID, /proc/PID/limits와 FD 수
- FD 종류별 집계와 시간에 따른 증가·회수 패턴
- 기존·변경 후 LimitNOFILE과 정상 부하 재검증 결과
BEFORE YOU START
이런 증상에서 시작합니다
- Too many open files 또는 EMFILE
- 새 연결·파일 열기 실패
- 재시작하면 잠시 정상화
- FD 수가 시간에 따라 계속 증가
CHECK THE BRANCH
놓치기 쉬운 원인 분기
서비스 limit에 도달
현재 FD 수가 프로세스 soft limit에 가깝고 사용량이 안정적이면 워크로드에 맞는 제한 조정을 검토합니다.
FD가 계속 증가
제한을 높여도 재발하므로 파일·소켓을 닫지 않는 애플리케이션 누수와 특정 요청 패턴을 먼저 조사합니다.
셸 ulimit과 서비스가 다름
로그인 셸의 ulimit은 systemd 서비스에 그대로 적용되지 않을 수 있으므로 프로세스 limits와 LimitNOFILE을 기준으로 판단합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
오류 시각과 대상 PID 확인
SERVICE_NAME을 실제 unit으로 바꾸고 오류를 낸 프로세스의 PID를 확인합니다.
서비스 상태
systemctl status SERVICE_NAME --no-pager -l최근 FD 오류
journalctl -u SERVICE_NAME --since '-30 min' -g 'Too many open files|EMFILE' --no-pager서비스 PID
systemctl show SERVICE_NAME -p MainPID --value결과 읽기
MainPID가 0이거나 재시작됐다면 장애 시각의 이전 PID와 로그를 별도로 확보합니다.
다음 판단
현재 또는 장애 당시 PID를 다음 단계에 사용합니다.
조회시스템을 변경하지 않는 확인 단계
프로세스 limit과 실제 FD 수 비교
PID_NUMBER를 대상 PID로 바꾸고 soft·hard limit과 사용량을 같은 시점에 비교합니다.
프로세스 limits
cat /proc/PID_NUMBER/limits현재 FD 수
find /proc/PID_NUMBER/fd -maxdepth 1 -type l 2>/dev/null | wc -lsystemd 설정값
systemctl show SERVICE_NAME -p LimitNOFILE결과 읽기
현재 FD 수가 Max open files의 soft limit에 가까운지 확인합니다.
다음 판단
여유가 있는데 오류가 났다면 child process, 컨테이너 또는 다른 PID를 확인합니다.
주의서버 부하나 권한을 고려할 단계
열린 대상 종류와 증가 패턴 확인
lsof는 FD가 매우 많은 프로세스에서 출력과 부하가 커질 수 있으므로 한 PID로 제한합니다.
FD 종류 요약
sudo lsof -nP -p PID_NUMBER | awk 'NR>1 {count[$5]++} END {for (type in count) print count[type], type}' | sort -n네트워크 소켓 요약
ss -s다시 센 FD 수
find /proc/PID_NUMBER/fd -maxdepth 1 -type l 2>/dev/null | wc -l결과 읽기
REG, IPv4·IPv6, FIFO 등 특정 종류가 증가하는지와 요청량 감소 후 FD가 반환되는지 봅니다.
다음 판단
지속 증가하면 limit 조정보다 애플리케이션 누수 분석을 우선합니다.
조회시스템을 변경하지 않는 확인 단계
프로세스와 시스템 전체 제한 구분
프로세스별 EMFILE과 시스템 전체 ENFILE 가능성을 구분합니다.
시스템 파일 핸들
cat /proc/sys/fs/file-nr시스템 최대 핸들
cat /proc/sys/fs/file-maxunit 원본과 drop-in
systemctl cat SERVICE_NAME결과 읽기
file-nr의 할당 수가 file-max에 가깝지 않다면 해당 프로세스 제한 또는 누수 가능성이 큽니다.
다음 판단
필요 동시 연결·파일 수를 근거로 새 limit 값을 승인받습니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
승인된 서비스 limit을 적용하고 재검증
LIMIT_VALUE를 측정 근거가 있는 값으로 바꾸며 누수를 숨기기 위한 임의의 큰 값은 사용하지 않습니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
서비스 override 편집
sudo systemctl edit SERVICE_NAMEunit 설정 다시 읽기
sudo systemctl daemon-reload서비스 재시작
sudo systemctl restart SERVICE_NAME적용값 확인
systemctl show SERVICE_NAME -p MainPID -p LimitNOFILE결과 읽기
새 PID의 /proc/PID/limits에 승인값이 적용되고 정상 부하에서 FD가 안정적으로 회수되어야 합니다.
다음 판단
FD가 계속 증가하면 이전 값 복원보다 먼저 트래픽 보호와 애플리케이션 수정 계획을 진행합니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.