File Descriptor

1. File Descriptor 1024는 왜 부족하고, 65536은 왜 충분한가?

ISS-162) Proxmox LXC Nginx 500 에러에서 Proxmox LXC의 Nginx가 (24: No file descriptors available) 에러를 뱉으며 뻗어버린 문제를 해결했습니다. 범인은 어이없게도 ulimit -n의 기본값인 1024였죠.

그래서 해결책으로 65536이라는 숫자를 적용했습니다. 근데 이런 의문이 들더군요.

1. 65536도 언젠간 다 소모되는 거 아닌가?

2. FD가 주기적으로 초기화(재사용)되는 거라면, 1024는 왜 부족했던 거지?

3. 왜 하필 65536인가? 그냥 10000이나 50000도 아니고.

2. FD는 소모품이 아니라 ‘재활용 대기표’다

가장 먼저 가졌던 의문, “65536도 언젠가 다 쓰면 뻗는 거 아닌가?”부터 알아봅시다.

결론부터 말하면, FD는 소모품이 아닙니다. ISS-162에서 “대기표”라고 비유했던 이유가 여기 있습니다.

• FD는 프로세스(Nginx)가 파일이나 네트워크 소켓을 열 때마다 커널로부터 받는 ‘번호표’입니다.

• 작업이 끝나고 파일이나 소켓을 닫으면(close), 이 번호표는 즉시 커널에 반납됩니다.

• 반납된 번호표는 다른 요청이 즉시 재사용할 수 있습니다.

즉, ulimit -n 65536의 의미는 ‘누적 65536번’ 사용 가능하다는 뜻이 아니라, **“동시에 최대로 열어둘 수 있는 파일/소켓의 개수가 65536개”**라는 뜻입니다.

100만 명의 유저가 방문했어도, ‘동시에’ 접속한 유저가 100명이라면 FD는 그 100명(+a)만큼만 사용되고 있을 뿐입니다. 방문자가 접속을 끊으면 FD는 바로 재활용됩니다.

3. 1024가 배신한 이유: ‘순간 피크’를 버티지 못했다

“아니, FD가 그렇게 빨리 재활용된다면서 1024개로 왜 부족했던 건데?”

이게 바로 ISS-162 문제의 핵심입니다. 1024가 부족했던 이유는 Nginx 같은 프록시 서버의 숙명 때문입니다.

Nginx는 중개자입니다.

1. 클라이언트(브라우저)가 Nginx에 접속합니다. (FD 1개 소모)

2. Nginx는 이 요청을 받아 내부 서버(DoEatFit, Jenkins 등)로 다시 연결합니다. (FD 1개 추가 소모)

단순 계산으로 방문자 1명이 최소 2개의 FD를 사용합니다. 하지만 현실은 더 가혹합니다.

• 현대 웹의 특징: 요즘 웹사이트는 수많은 정적 파일(CSS, JS)과 API 요청으로 이루어집니다.

• Keep-Alive & HTTP/2: 연결 효율을 위해 한 명의 유저가 동시에 수십 개의 연결을 열어두는 경우가 흔합니다.

• 로그 파일: Nginx는 access.log, error.log 등 로그 파일도 열어둬야 합니다. (FD 추가 소모)

1024라는 숫자는 이 모든 것을 감당하기엔 너무 작았습니다. 유저 한 명이 20개의 FD를 사용한다고 가정하면, 동시 접속자 50명만 몰려도 1024개의 창구는 꽉 차버립니다.

51번째 유저가 접속을 시도하는 순간, Nginx는 “대기표(FD) 다 떨어졌습니다” (No file descriptors available) 라며 500 Internal Server Error를 뱉어버린 것입니다.

1024가 부족했던 것은 FD가 재활용되지 않아서가 아니라, 재활용되는 속도(연결 종료)보다 소모되는 속도(새 연결)가 순간적으로 더 빨랐기 때문입니다. 이 ‘순간 피크’를 버틸 버퍼가 너무 작았던 거죠.

4. 65536은 왜 ‘국룰(Standard)‘이 되었나?

그럼 왜 10000도 아니고 50000도 아니고 65536일까요?

4-1. 2의 16제곱 ($2^{16}$)

65536은 $2^{16}$입니다. 컴퓨터 공학에서 아주 익숙한 숫자죠.

• 16비트의 유산: 과거 16비트 시스템에서 표현할 수 있는 최대 숫자(0~65535)였습니다.

• 네트워크 포트: 우리가 아는 TCP/UDP 포트 번호의 범위가 0번부터 65535번까지인 것과 같은 맥락입니다.

• 관습적인 ‘충분히 큰 수’: 기술적으로 꼭 이 숫자여야 할 필연적인 이유는 없지만, 시스템 리소스를 표현할 때 “이 정도면 넉넉하지”라는 의미로 사용되는 관습적인 숫자입니다.

4-2. 현실적인 타협점

FD 한도는 공짜가 아닙니다. 커널은 열려있는 FD 목록을 관리하기 위해 메모리를 사용합니다.

• 너무 낮으면 (1024): ISS-162처럼 서버가 터집니다.

• 너무 높으면 (e.g., 1,000,000): 가능은 하지만, 모든 프로세스에게 이렇게 큰 한도를 주면 그만큼 커널 메모리 부담이 커집니다.

• 65536 (국룰): “왠만한 중소규모 트래픽의 웹서버(Nginx)가 감당하기에 차고 넘치며, 동시에 커널 메모리에도 큰 부담을 주지 않는, 경험적으로 검증된 넉넉한 기본값”입니다.

물론, 초당 수만 명의 동시 접속을 처리하는 네이버나 구글 같은 대규모 서비스는 이 값을 1048576 ($2^{20}$) 이상으로 튜닝해서 사용하기도 합니다.

5. 결론: 기본값을 믿지 말자

ISS-162와 이번 공부를 통해 얻은 교훈은 명확합니다.

1. FD는 재활용된다. 65536은 ‘동시 접속’ 한도이지, ‘누적 방문’ 한도가 아니다.

2. 1024는 현대 웹 프록시 서버에겐 너무 가혹한 숫자다. 순간 피크 트래픽을 버티지 못한다.

3. 65536은 경험적으로 검증된 ‘국룰’이다. 대부분의 서비스에 넉넉한 버퍼를 제공한다.

가장 중요한 교훈은 이것입니다. “리눅스의 기본값(1024)을 맹신하지 말자.” 특히 Nginx, DB 서버처럼 수많은 연결을 처리해야 하는 녀석을 설치했다면, ulimit -n 값부터 확인하고 65536으로 올려두는 것이 정신 건강에 이롭습니다.

---