Cloud에서 발생하는 File Descriptor 문제 해결하기
Updated:
Cloud에서 발생하는 File Descriptor 문제 해결하기
Cloud의 Tomcat에 설정되어 있던 900개(6개 POD에 각가 150개 Pool 사용)의 DB Connection Pool이 사라진다.
그리고 새로운 900개의 DB Connection Pool이 생성된다.
이러한 현상이 거의 매일 반복되지만 원인을 알 수 없다.
현상이 발생하는 시점에는 사용자의 요청이 정상적으로 처리 되지 않고 응답시간 대기 현상이 발생하여 고객들의 불만이 자자하다.
왜 DBCP의 모든 Pool이 사라지는 것일까?
DBCP에 어떤 문제가 있었던 것인지 그 원인을 알아보기로 한다.
DB Connection Pool 유실 현상
위 DB Connection Pool 추이 그래프를 보면 오전 6시 경 인터넷 쇼핑몰의 900개의 DB Pool이 순차적으로 유실되는 현상이 발생하고 사용자 요청이 들어오기 시작하는 오전 9시 경에 DB Pool이 900개로 증가되는 것이 확인된다.
또 다른 날의 DB Connection Pool 추이 그래프를 보면 특이한 현상이 확인된다.
15:35~39 경에 DB Connection Pool이 새로 생성되는 것이 확인된다.
그 시점에 Socket 추이를 보면 1000개 이상의 사용량이 급격히 증가하는 현상이 발생한다.
해당 시간의 Jennifer X-View를 확인해 보면 실시간 트랜잭션의 수집 데이터도 유실되는 현상이 발생했던 것을 알 수 있다.
위 현상 발생 시점 Jennifer의 수집서버 로그를 확인해 보면 수집서버와 에이전트 간의 Connection이 일시적으로 끊겼다가 다시 연결되면서 트랜잭션 정보가 수집되지 못한 것을 알 수 있다.
File Descriptor 설정 점검
Socket 값이 증가하고 서버와 서버 사이의 연결이 끊기는 현상이 발생하는 경우 Linux의 File Descriptor(open files, nofile) 설정값을 점검해 볼 필요가 있다. Linux에서는 Socket과 File이 동일하게 취급되기 때문이다.
ulimit 명령어 사용하기
ulimit 명령어의 간단한 사용법과 옵션은 아래와 같다.
| 명령어 | 설명 |
|---|---|
| ulimit | Process의 자원 한도를 설정하는 명령어. soft limit과 hard limit이 있음 |
| Options | -a : 모든 limit 설정값을 조회 -c : Max Core File Size -d : Max Data Segment Size -f : shell에 의해 만들어질 수 있는 File의 Max Size -s : Max Stack Size -p : Pipe Size -n : Open Files 최대 갯수 -u : Max User Processes -v : Max Virtual Memory -S : soft limit -H : hard limit |
| 설정 | 설명 |
|---|---|
| open files(nofile) | 해당 도메인(사용자, 그룹)이 오픈할 수 있는 최대 파일 개수(default 1024) |
위와 같이 ulimit -an 명령어를 수행하여 현재 설정된 open files 값을 확인할 수 있다.
문제가 발생한 WAS의 open files 설정값을 조회한 결과 default 설정값인 1024로 확인되었다.
현상이 발생했던 시점의 Socket 사용량이 1024를 넘어서다가 갑자기 줄어드는 현상을 확인할 수 있는데 이는 open files 최대 설정값인 1024에 도달하면서 사용 중인 연결이 모두 reset되어 연결이 끊긴 것이다.
따라서 DB Connection Pool이 사라지는 현상은 open files 설정값이 너무 작게 설정되어 생기는 문제라고 볼 수 있다.
File Descriptor(Open Files) 설정값 변경하기
File Descriptor(Open Files) 설정값 변경은 아래와 같이 사용자별 또는 커널 설정 변경을 통해 처리할 수 있으며, 변경을 위해서는 root 권한과 서버 재기동이 필요하므로 서버 담당자에게 변경을 요청하여 처리할 것을 권장 한다.
추천되는 설정값은 여유 있게 65536 정도를 권장한다.
- 사용자별로 설정하기
/etc/security/limits.conf 파일에 아래와 같이 설정을 추가
설정 예)
root hard nofile 65536
root soft nofile 65536
- 커널 설정 변경하기
다음과 같이 커널 설정 조회
cat /proc/sys/fs/file-max
sysctl fs.file-max
/etc/sysctl.conf 파일에 아래와 같이 설정을 추가
설정 예)
fs.file-max=66536
DB Connection Pool 유실과 재연결 현상 해결!
File Descriptor 설정값을 변경하고 1일 간 DB Connection Pool 사용량과 Socket 사용량 추이를 모니터링하였다.
설정 변경 이전에는 Socket 사용량이 약 1000개~1400개 정도에서 현상이 발생하였으나 설정 변경 후에는 2000개 이상의 Socket이 사용되고 있는 것으로 확인되었다.
DB Connection Pool이 대량으로 유실되었다가 재연결되는 현상이 더이상 발생하지 않았다.
마찬가지로 Jennifer의 수집서버과 에이전트 간의 끊김 현상도 발생하지 않는 것으로 확인되었다.
8개월 이상 반복되던 DB Connection Pool의 유실 현상이 드디어 해결된 것이다.
문제 해결의 끝에는 또다른 문제가 시작된다…
영화에서 천신만고 끝에 주인공이 빌런을 처리하며 모든 것이 해결된 것으로 끝나지만 엔딩 크레딧 뒤에 쿠키 영상이 나오며 더 강력한 빌런이 다시 나타날 것을 암시하며 끝나는 경우가 많은 것처럼…
DB Connection Pool 유실 문제를 해결하고 나니 한 번도 경험해 보지 못한 또다른 DB Connection Pool 문제가 드러나기 시작했다.
심판이 경기 끝을 선언하기 전까지는 경기가 끝이 아닌 것처럼 다시 문제 해결에 나서야 했다.
또 다른 DB Connection Pool 문제는 다음 이야기에서 소개하기로 한다.