strace를 통해 젠킨스 트러블 슈팅 하기
Linux Performance
오늘은 strace 명령을 통해서 젠킨스 서버에서 발생한 이슈를 해결한 이야기를 해볼까 합니다. 특히 원인 불명으로 CPU의 사용률이 높아져 서버가 먹통이 되는 현상을 strace 명령의 도움을 통해서 해결한 이야기 입니다. 그럼 시작해 보겠습니다.
사건의 발단
사건의 발단은 이렇습니다. 아무 문제 없이 운영 중이던 젠킨스 서버가 갑자기 아무런 작업도 할 수 없을 만큼 먹통이 되는 일이 발생 했습니다. 하지만 이 현상은 일정 시간이 지나면 풀렸다가 다시 먹통이 되는 식으로 주기성을 가지고 반복적으로 발생 했습니다.
CPU 사용량 그래프뭔가 주기적으로 실행 되면서 성능에 영향을 끼치고 있었지만 의심이 가는 젠킨스의 배치 작업들을 비활성화 해봐도 상태는 좀처럼 나아지지 않았습니다.
시간이 지나도 상황은 나아지지 않았고 고민 하던 끝에 strace를 이용해 프로세스가 어떤 작업을 하는지 추적 해보기로 했습니다.
strace를 통해 프로세스 추적하기
strace 명령을 통해 젠킨스 프로세스의 동작을 추적하던 중 이상한 현상을 발견하게 되었습니다. A 라는 쓰레드가 새롭게 생성되어 뭔가 작업을 한 후 종료되는 것이었습니다. 그리고 A 쓰레드에서 발견된 strace 데이터는 아래와 같았습니다.
18041 16:26:02 <... futex resumed> ) = 0
28890 16:26:02 <... read resumed> "\n</string>\n <string>2020-06-26 17:02:28.846 INFO 114 --- [ main] c.b.w.batch.job.SubscriptionCheckBatch : Processing active userId: 5693180\n</string>\n <string>2020-06-26 17:02:28.847 INFO 114 --- [ main] c.b.w.batch.job.SubscriptionCheckBatch : Processing active userId: 5693216\n</string>\n <string>2020-06-26 17:02:28.848 INFO 114 --- [ main] c.b.w.batch.job.SubscriptionCheckBatch : Processing active userId: 5693224\n</string>\n <string>2020-06-26 17:02:28.849 INFO 114 --- [ main] c.b.w.batch.job.SubscriptionCheckBatch : Processing active userId: 5693226\n</string>\n <string>2020-06-26 17:02:28.850 INFO 114 --- [ main] c.b.w.batch.job.SubscriptionCheckBatch : Processing active userId: 5693231\n</string>\n <string>2020-06-26 17:02:28.851 INFO 114 --- [ main]
뭔가 좀 이상 했습니다. strace를 통해 추적한 당일은 2020년 7월 3일이었지만 strace 상에 찍혀 있는 데이터는 2020년 6월 26일의 데이터 였습니다.
2020년 6월 26일에 실행된 배치 작업의 로그를 read() 시스템 콜을 통해서 읽고 있는 형태의 작업 기록이 strace 추적을 통해 남아 있었습니다.
아마도 이 쓰레드가 순간적으로 부하를 일으켜서 서버를 먹통으로 만들고 종료되고 나면 서버가 다시 살아나게 되는 것은 아닐까 의심이 되었습니다. 그래서 오래된 로그를 삭제하는 것과 관련된 젠킨스의 여러 설정들을 찾아보던 중 가장 유력한 용의자를 발견 했습니다.
Project Build Discarder
젠킨스의 글로벌 설정 중 Project Build Discarder 의 설정으로 인해 주기적으로 오래된 배치 작업들의 로그가 삭제되고 있었고, EFS를 사용하고 있는 젠킨스의 특성 상 한 번에 많은 양의 작업이 몰릴 경우 부하를 일으킬 수 있었습니다.
문제를 일으켰던 설정결국 이 설정을 삭제하고 나서 젠킨스 서버는 주기적으로 튀는 현상이 없어지고 다시 안정적인 상태로 돌아갈 수 있었습니다.
아름다운 CPU 사용량 그래프로 다시 변신마치며
사실 EFS를 사용하지 않았다면 발생하지 않았을 수도 있을 문제이기 때문에 다른 곳에서도 발생할 수 있을 만한 흔한 이슈는 아닙니다. 하지만 문제의 해결 과정에서 strace라는 툴을 사용했고 거기서 힌트를 얻어서 해결했다는 것이 의미 있기 때문에 한 번쯤 공유 해보고 싶었습니다.
strace 툴은 서비스 환경에서 바로 사용하기에는 위험한 부분이 있는 툴 입니다. 젠킨스 서버의 경우는 잠깐 젠킨스가 안되도 큰 문제가 없지만 서비스 환경의 서버에서 사용할 때는 반드시 주의해서 사용해야 합니다. 가장 좋은 방법은 개발 혹은 테스트 환경을 서비스 환경과 동일하게 만들어 놓고 증상이 재현되도록 한 후에 strace를 활용하는 것 입니다.
strace에 대한 조금 더 자세한 설명은 제가 이전에 작성한 글 https://brunch.co.kr/@alden/12 에도 있으니 필요하시면 참고하시기 바랍니다.
ps. 문제를 함께 해결하는데 도움을 주신 송주영 님과 이승우 님에게 감사의 뜻을 전합니다!
