본문 바로가기
트러블 슈팅

SSE Too many open files (feat. Docker)

by CodingMasterLSW 2026. 4. 5.

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를 확인해보시면 좋을 것 같네요ㅎ_ㅎ