쓰레드가 너무 많아서 Thread dump를 떠 봤다.

내 옆자리 블루스가 서버군 중 하나의 지표를 모니터링 하던 중, 예상한 것 보다 너무 많은 쓰레드가 생성 된 것을 발견하셨다. 쓰레드가 너무 많은 것은 성능 상에 좋지 않다. 불필요하게 쓰레드가 많이 사용될 경우 그만큼 쓰레드 생성, 관리에 불필요한 오버헤드가 발생한다. 또한 많은 쓰레드가 하드웨어 자원을 공유하는 과정에서 성능 저하가 발생한다. 그래서 Thread dump를 떠봤다. 여러가지 툴이 있었지만 웹으로 개발된 Fast Thread가 UI도 직관적이고 접근하기가 편리했다.

쓰레드 덤프를 뜨는 방법은 여러가지가 있다.

kill -9 $pid 명령어를 사용하면, /tmp/hsperfdata_deploy/ 에 pid를 이름으로 하는 덤프 파일이 생긴다.

하지만 이렇게 생성한 thread dump의 형식이 fast thread 에서 사용할 수 없는 형식이라 jstack을 사용했다.

jstack -l  <pid> > <file-path>

이렇게 생성한 thread dump 파일을 scp를 이용해 로컬 머신으로 가져오고, Fast Thread 를 이용해 분석해보았다.

쓰레드 상태에 따른 개수, 쓰레드 그룹에 따른 개수, 데몬인 쓰레드와 아닌 쓰레드의 개수, identical stack trace, CPU 소모가 많은 쓰레드 등을 보여준다.

우리가 쓰레드 덤프를 해본 이유는 쓰레드의 개수가 생각보다 많아 어디서 생성 됐는지 파악하기 위함이었으므로, 메인 페이지에서 제공해주는 요약본만으로도 충분한 도움이 됐다.

우선 어떤 쓰레드 그룹이 얼마나 쓰레드를 많이 생성 했는지 확인할 수 있었다.

Screen Shot 2019-03-21 at 9.46.00 PM

하지만, 기본 쓰레드 그룹 이름이 할당 되어 쓰레드 그룹의 용도나 출처를 파악하기 힘든 그룹이 있었다. 쓰레드를 생성할 때는 쓰레드 이름을 적절히 꼭 붙여야 겠다는 생각이 들었다.

이름이 붙지 않았거나 우리가 의도하지 않았기에 출처가 애매한 쓰레드 그룹들은 stack trace를 통해 확인할 수 있었다. 특히 stack trace를 flame graph로 표현한 부분을 통해 직관적으로 어디서 쓰레드가 생성 됐는지 알기 쉬었다.

Screen Shot 2019-03-21 at 9.41.49 PM.png

이렇게 생성된 쓰레드 그룹과 스택 트레이스를 확인함으로써 어떤 배포의 어떤 기능에서 추가적으로 쓰레드를 생성해서 사용하고 있는지 찾아낼 수 있었다.

이렇게 오랜만에 쓰레드 수와 사용처를 확인한 블루스는 ServletExecutor를 따로 쓰므로 worker threads가 필요 없을 것 같다며, worker threads를 줄여 커밋하셨다.

다소 가벼운? 이유로 thread dump를 떠보았다. thread dump의 유용성에 대해서는 다음 글을 통해 배울 수 있었다.

https://d2.naver.com/helloworld/10963

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

search previous next tag category expand menu location phone mail time cart zoom edit close