리눅스에서 'Too many open files' 오류 해결하기

증상

리눅스 환경에서 애플리케이션을 실행할 때, ‘Too many open files’라는 오류 메시지를 자주 접할 수 있습니다. 이 오류는 시스템의 파일 디스크립터 한도를 초과했을 때 발생합니다. 예를 들어, 웹 서버가 많은 클라이언트 요청을 처리하려고 할 때, 파일 핸들이 제대로 닫히지 않거나, 너무 많은 파일을 동시에 열 경우 이 문제가 발생할 수 있습니다. 오류 메시지는 보통 다음과 같습니다:

OSError: [Errno 24] Too many open files

이 오류가 발생하면 애플리케이션이 정상적으로 작동하지 않거나, 새로운 파일을 열 수 없는 상태가 됩니다.

원인

‘Too many open files’ 오류의 주요 원인은 다음과 같습니다:

파일 디스크립터 누수: 파일이나 소켓을 열고 닫지 않으면, 사용 가능한 파일 디스크립터가 소모되어 누적됩니다.
시스템 파일 디스크립터 제한 초과: 기본적으로 리눅스는 사용자당 열 수 있는 파일 수를 제한합니다. 이 한도를 초과하면 새로운 파일을 열 수 없습니다.
비효율적인 코드: 반복문 내에서 파일을 열고 닫지 않거나, 객체를 매번 새로 생성하는 경우도 누수를 유발할 수 있습니다.

확인 명령어

문제를 진단하기 위해 다음 명령어를 사용할 수 있습니다:

현재 프로세스의 파일 디스크립터 수 확인:
```
lsof -p {PID} | wc -l
```
시스템의 최대 파일 디스크립터 수 확인:
```
cat /proc/sys/fs/file-max
```
특정 프로세스의 파일 디스크립터 한도 확인:
```
prlimit --nofile --pid {PID}
```
현재 사용자에 대한 ulimit 확인:
```
ulimit -n
```

해결 절차

파일 디스크립터 한도 증가: ulimit 명령어를 사용하여 현재 세션의 파일 디스크립터 한도를 증가시킬 수 있습니다. 예를 들어:
```
ulimit -n 4096
```
그러나 이 설정은 세션이 종료되면 초기화됩니다.
영구 설정 변경: /etc/security/limits.conf 파일을 수정하여 모든 사용자 또는 특정 사용자에 대한 파일 디스크립터 한도를 영구적으로 설정할 수 있습니다. 예:
```
* soft nofile 4096
* hard nofile 4096
```
설정 후, 세션을 종료하고 재접속해야 변경 사항이 적용됩니다.
코드 수정: 파일이나 소켓을 열 때는 반드시 닫는 것을 잊지 마세요. 예를 들어, Go 언어에서는 defer 키워드를 사용하여 파일을 열고 나중에 자동으로 닫을 수 있습니다:
```
f, err := os.Open("file.txt")
if err != nil {
    log.Fatal(err)
}
defer f.Close()
```
모니터링: lsof와 prlimit 명령어를 사용하여 주기적으로 열린 파일 수를 모니터링하여 누수를 조기에 발견할 수 있습니다.

재발 방지 체크리스트

파일이나 소켓을 열 때 항상 닫기
시스템의 파일 디스크립터 한도를 정기적으로 점검하기
애플리케이션의 파일 사용 패턴을 분석하여 비효율적인 부분 개선하기
서버의 부하를 고려하여 적절한 파일 디스크립터 한도로 설정하기

이와 같은 조치를 통해 ‘Too many open files’ 오류를 예방하고, 시스템의 안정성을 높일 수 있습니다.

실무 적용 체크리스트

too many open files 해결을 적용하기 전에 현재 운영 환경의 기준값과 예외 상황을 먼저 정리합니다.
변경 전후로 확인할 지표를 정하고, 문제가 생겼을 때 되돌릴 수 있는 절차를 문서화합니다.
한 번에 모든 서버나 서비스에 적용하기보다 작은 범위에서 검증한 뒤 점진적으로 확대합니다.
담당자, 확인 시간, 장애 판단 기준을 명확히 남겨 같은 문제가 반복될 때 빠르게 대응할 수 있게 합니다.

참고 이미지

이미지 출처: https://wildeveloperetrain.tistory.com/318

운영 중 자주 놓치는 부분

#Linux 영역에서는 설정 자체보다 운영 중에 남는 기록과 점검 루틴이 더 중요합니다. 처음에는 정상처럼 보이더라도 트래픽이 늘거나 배포 주기가 빨라지면 작은 누락이 장애로 이어질 수 있습니다. 그래서 로그, 알림, 대시보드, 변경 이력을 함께 확인하고 실제 장애 대응 과정에서 필요한 정보가 빠지지 않았는지 주기적으로 점검해야 합니다.

증상

원인

확인 명령어

해결 절차

재발 방지 체크리스트

실무 적용 체크리스트

운영 중 자주 놓치는 부분

참고한 자료

Related posts