Too many Open Files 발견...!! 이유가 뭘까??

Too many open files 에러가 발생했다는건, File Descriptor의 최댓값을 초과한 상황입니다. File Descriptor 설정을 따로 건드린 적은 없는데... 왜 갑자기 에러가 발생했을까요?? 트래픽이 갑작스럽게 증가한 상황도 아닌데...
에러의 원인은 도커 엔진 업데이트였습니다.🙄
File Descriptor의 초기 설정
Linux File Descriptor 초기값

Linux 환경에서는 프로세스별 File Descriptor의 기본 soft limit이 1024입니다. 이 상황에서 애플리케이션을 직접 실행하면 1024개의 FD만 사용할 수 있어, SSE 연결이 약 1,000개를 넘는 시점에서 Too many open files 에러가 발생합니다.
하지만 기존 서버는Docker 컨테이너 위에서 애플리케이션을 실행하고 있기에, 리눅스의 File Descriptor의 초기값과는 무관한 상황이었습니다.
Docker 환경에서의 기존 file descriptor(nofile) 값

별도의 file descriptor 설정을 하지 않으면, docker측에서 약 100만의 fd를 max값으로 설정을 해줍니다. 이 때문에 별도로 file descriptor의 설정을 건드리지 않아도 에러가 나지 않았던 것이죠.
2026년 3월 25일에 docker engine v29가 release 되었는데요,
https://docs.docker.com/engine/release-notes/29/
Engine v29
Learn about the new features, bug fixes, and breaking changes for Docker Engine
docs.docker.com

해당 업데이트에서 file descriptor의 기본값이 1048576 -> 1024로 변경되었다는 것을 확인할 수 있었습니다.
도커 엔진 업데이트 후

file descriptor의 최댓값이 약 100만 -> 1024로 줄어들어서 발생한 Too many open files 에러였습니다ㅎ
도커는 왜 이런 업데이트를 진행했을까?🧐
일부프로그램들은 실행될 때 ulimit 값을 확인하고, 이에 맞춰 미리 메모리를 할당하거나 동작 방식을 결정한다고 합니다. file descriptor의 max값을 읽고 fd를 관리할 자료구조를 미리 할당하는데, 자료구조에 너무 큰 공간을 미리 잡아버려서 메모리 낭비가 발생한다...! 라는 얘기더라고요. (100만개면 100만개 들어갈 공간을 만들어야하니) 참고로 JVM에서는 발생하지 않는 문제입니다.
해결방안
현재 서버를 docker-compose를 통해 띄우고 있기에, 명시적으로 file descriptor 용량을 적어주었습니다.
services:
feed-zupzup:
image: codingmasterlsw/jenson-feed-zupzup:latest
container_name: feed-zupzup
ports:
- "8080:8080"
ulimits:
nofile:
soft: 16384
hard: 16384
도커 엔진 업데이트 후 Too many open files 오류가 발생한다면 file descriptor를 확인해보시면 좋을 것 같네요ㅎ_ㅎ
'트러블 슈팅' 카테고리의 다른 글
| SSE 연결 끊김 트러블슈팅: HttpLoggingFilter와 Content-Length 충돌 (0) | 2025.12.07 |
|---|---|
| CORS Policy 에러 (3) | 2025.07.27 |
| 자동 배포 workflow 외부 IP 접근 불가 (feat. self-hosted) (1) | 2025.07.17 |
| exec /usr/java/openjdk-21/bin/java: exec format error (3) | 2025.07.17 |
| github actions 배포 스크립트 no such file or directory 에러 (1) | 2025.07.13 |