올해 2월 중에 겪었던 장애 내용에 대해 관련 내용을 정리하고자 합니다.
장애 상황은 다음과 같습니다.
현재 제가 맡은 업무 도메인의 경우 API 산출 결과 데이터를 MongoDB에 실시간을 적재하고 있습니다.
언제나 그렇듯 업무를 보던 중에 모니터링 시스템에서 MongoDB가 셧다운 되었다는 알람이 울리게 되었으며 DB 로그 확인 결과 'too many open files' 라는 에러가 찍혀있는 것을 확인하였습니다.
그래서 이번 포스팅은 too many open files라는 에러의 원인과 내용에 대해 정리하려고 합니다.
'too many open files'의 직접적인 원인은 프로세스가 OS에 요청할 수 있는 최대 open 가능한 파일 개수에 limit이 있으며 프로세스가 그 제한을 넘었기 때문에 발생한 것입니다.
이때, open 가능한 파일이란 것은 소켓(HTTP, JDBC 커넥션 등)을 포함한 파일 개수입니다.
프로세스의 limit의 경우 프로세스를 실행한 계정의 limit을 참고하여 설정되기 때문에 계정, 프로세스 limit 모두 확인이 필요합니다.
따라서 'too many open files' 문제의 경우 계정 limt과 프로세스에 대한 limit 두 가지를 보며 해결하도록 하겠습니다.
우선 Limit의 경우 크게 Soft, Hard 두 가지 종류가 존재합니다.
특징은 아래와 같습니다.
이어서 프로세스가 실행되고 있는 계정의 NOFILE Limit을 확인하도록 하겠습니다.
아래 두 가지 명령어를 통해 확인 가능합니다.
soft, hard 모두 변경을 위해서는 root 계정에서 변경이 가능합니다.
/etc/security/limits.conf 파일에 아래 구문을 추가하도록 하겠습니다.
우선 예시로 500000으로 설정하였으며 구체적인 수치는 각 서버의 상황에 따라 설정해주시면 됩니다.
하지만 이때 주의할 사항이 있습니다.
새로 설정한 500000, 즉 limit 값의 경우 system 전체 limit 보다 작아야합니다.
system 전체 limit은 아래 명령어로 확인 가능합니다.
마지막으로 계정의 limit을 변경했다면 터미널을 통해 재 로그인 해주시면 변경이 완료됩니다.
프로세스 limit의 경우 변경한 뒤 재시작을 하면 되지만 실시간 서비스 환경에서 프로세스 재시작이 안되는 때가 있다고 가정하고 작성하도록 하겠습니다.
먼저 limit을 변경하기 전 해당 프로세스의 PID를 확인해야 하기 때문에 아래 명령어를 통해 PID를 확인합니다.
방금 확인한 PID를 기준으로 해당 프로세스의 limit을 확인하도록 하겠습니다.
마지막으로 limit을 변경하도록 하겠습니다.
위처럼 변경을 하면 프로세스 재시작없이 soft, hard limit을 변경 가능하게 됩니다.
OS 레벨에서의 설정을 만질일은 거의 없지만 해당 장애를 통해 새로운 것을 알게 되었습니다.
too many open files 이슈에 대한 해결방법을 정리해보았습니다.
계정의 limit을 확인한 다음 프로세스에 대한 limit을 변경하게 되면 정상적으로 외부요청을 받을 수 있는 것을 확인하실 수 있으실 수 있을 겁니다.