ch02
2. 시스템 지연 발생 주요 모니터링 고려사항 3. 쓰레드 덤프란 4. Jmeter를 활용한 기본 성능 테스트 5. lib 주의사항 6. 장애분석 실무 사례 Jmeter를 활용한 기본 성능 테스트 : 부하량 관련 / 부하가 있을 경우 web was 현상 누적된 처리량, 현재 처리량 (예상 시나리오를 가지고 부하를 던진 후 퍼포먼스 파악) |
1. 시스템 지연 발생 주요 모니터링 방법
1) 장비를 나눠서 서버 검정 → 각각의 부하량에 대해서 얼만큼 부하량을 감당하는지, 튜닝 포인트 판단 가능(물리적 리소스 단위 나눌 필요가 있음)
2) Jmeter로 여러대의 서버에서 네트워크 traffic을 유발시켜서 부하를 줌 (그래서 어디서 병목 현상이 일어나는지 알 수 있음)
2. 시스템 지연 발생 주요 모니터링 고려사항
1) db low query 가 최종 client한테 도달하는 시간까지 고려해야함
- db안에서 3초까지 튜닝해도 client 도달 시간이 아님
2) nginx 의 상태 log와, 에러가지고 전체 판단하면 안됨
3) 설정값으로 인해 병목현상이 발생할 수 있음
ex. db에서 active session이 몇 개인지와 같이
( * session : db 와 연결돼있는 was connection, 실제로 붙은 db 개수, 실제 돌아가면 active section, 안돌아갈 경우 idle이라 부름 / network - network연결 상태(connection) / middleware - 몇명의 사용자가 들어왔는지 )
4) tomcat의 외부시스템 붙은 것과 내부 자바를 확인하려면 pid를 쫓아 가야만 함
5) os 상태 유입량 확인해야 함
tcp 0 0 10.217.69.71:8280 0.0.0.0:* LISTEN 12451/java tcp 0 0 127.0.0.1:10190 0.0.0.0:* LISTEN 12451/java tcp 0 0 10.217.69.71:8209 0.0.0.0:* LISTEN 12451/java TcpState 정의 CLOSED : tcp 연결이 닫혀있다 CLOSE_WAIT : TCP연결의 로컬 엔드포인트에서 로컬 사용자로부터의 연결 종료 요청을 기다리고 있다 CLOSING : TCP연결의 로컬 엔드포인트에서 이전에 보낸 연결 종료 요청의 승인을 기다리고 있다 ESTABLISHED : TCP hand-shake가 완료됨. 연결이 설정되었으므로 데이터를 보낼 수 있음 LISTEN : TCP 연결의 로켈 엔드포인트에서 원격 엔드포인트로부터 연결 요청을 수신하고 있음 TIME_WAIT : TCP연결의 로컬 엔드포인트에서 원격 엔드포인트가 연결 종료 요청의 승인을 받았는지 확인하는데 충분한 시간이 경과하기를 기다리고 있음 → 로컬 끝점은 원격 끝점이 승인을 수신했는지 확인하기 위해 CLOSED로 이동하기 전에 최대 세그먼트 수명(MSL)의 두배를 기다립니다. 내부시스템으로 확인해야함 2. 프로그램과 연결(연동)돼 있는 타 시스템/ 서버에 대해 확인하고 시작 tomcat : netstat -nap | grep 8009 | grep java apache - established 상태가 길지 않음(클라이언트 쪽이라) 현재 유입량 보기엔 작은 수치 |
3. 쓰레드 덤프란
tomcat은 자바가 올라갈 때 각각의 class들의 Thread가 일하고 있는 것들이 block 단위
( * thread : 경량 프로세스. 하나의 프레세스 내에서 여러 개의 실행 흐름(단일, 동시적, 병렬적)을 두어 작업을 효율적으로 처리하기 위한 모델 )
실제로 서비스 단위로 일하는 쓰레드는 유입량이 늘어남 → max user processes 내부 쓰레드 확 늘어나면서 차게 되면 더 이상 쓰레드 못쓰게 됨 <병목 발생>
“지금 상태를 사진으로 찍는다”
| echo "Thread dump collecting start..." export DATE=`date +%Y%m%d%H%M%S` echo "1st thread dump : "$DATE>>$ofile 2>&1 echo "<details> <summary> thread dump1 </summary><p>" >>$ofile 2>&1 ## jstack : thread dump comm jstack -l $1 > ./$DATE2/thread_dump1_$1.log cat ./$DATE2/thread_dump1_$1.log>>$ofile 2>&1 sleep 2 echo "</p></details>" >>$ofile 2>&1 export DATE=`date +%Y%m%d%H%M%S` echo "2nd thread dump : "$DATE>>$ofile 2>&1 echo "<details> <summary> thread dump2 </summary><p>" >>$ofile 2>&1 jstack -l $1 > ./$DATE2/thread_dump2_$1.log cat ./$DATE2/thread_dump2_$1.log >>$ofile 2>&1 sleep 2 echo "</p></details>" >>$ofile 2>&1 export DATE=`date +%Y%m%d%H%M%S` echo "3rd thread dump: "$DATE>>$ofile 2>&1 echo "<details> <summary> thread dump3 </summary><p>" >>$ofile 2>&1 jstack -l $PID > ./$DATE2/thread_dump3_$1.log cat ./$DATE2/thread_dump3_$PID.log >>$ofile 2>&1 #jstack -l $PID >>$ofile 2>&1 echo "</p></details>" >>$ofile 2>&1 echo "</PRE></TD></TR>">>$ofile 2>&1 echo "Thread dump collecting complete" |
(실제 덤프 떴던 스크립트)
덤프를 한 번만 찍는 것이 아닌, sleep2 (2초)간격을 두고 약 3번 이상 뜨는 것이 중요함
⇒ thread dump는 획등 당시의 thread 상태만 알 수 있기 때문. 2초간격을 두고 dump를 뜨게 될 경우 이슈 추론이 가능해짐
⇒ os도 이런 모니터링이 필요함 → 실질적인 서비스의 병목, 지연, holding의 원인이 됨
네트워크 상태, os 플랫폼도 고민해봐야 함
apache 유입(io) → 한 파일에 줄 세워서 쏨
tomcat 유입(io) → 일정 데이터 sweep하고 write 시킴
4. Jmeter 시나리오
|
(1번째 사진) (2번째 사진) 부하량 증가 → tps더 이상 증가하지 않고 유지 = tps처리 못한다는 의미 → 시스템측면에선 병목이 생기는 현상 |
지연 구간 안보임⇒ Normal 문제 발생 시나리오 추가 ⇒ testsleep , sleep_jsp |
|
#1초동안 찍은 쓰레드 덤프 tid가 같은 경우
⇒ 몇 개의 쓰레드 덤프를 나열해두고 흐름을 보면서 지연 원인 파악 (자바 베이스)쓰레드 덤프 jsp 컴파일 된 위치가 가서 지연유발하는 코드 확인 loop처리 : 1번째사진은 110, 2번째사진은 120같이 holding : db, network경우 홀딩 걸리는 경우도 있음 |
|
** 인프라 문제 해결 포인트 : 어디를 좁혀서 어디를 봐야할 지 ( ex.1초 이상인 것만 추려서 현상 확인 )
cpu가 튄다? → 메모리 상태 먼저 확인. “Jstat”jstack 0l PID >> test.thread2.logjstat -gcutil PID 2000
** 메모리 덤프 시, 서비스 자체가 홀딩되기때문에 함부로 덤프 뜨면 안됨
- tomcat, jvm 확인할수 있는 row data → thread dump
** 서버 자체의 memory , disk, 충분한 용량 필요 →
현재 instance 의 용량 * 3 +3 있어야 함 ⇒ 그래야 OOM를 확인할 수 있는 덤프 로그 확보 가능
** 기본설정과 ap설정 구분하여 쓸 것 (간혹 혼동하여 같이 쓰는 경우가 있음)
5. lib 주의 사항
| tomcat lib 엔진 기본 외 라이브러리에 올리면 안되는 이유 : ap있는 라이브러리와 엔진 라이브러리 버전이 틀리면 무엇이 먼저 로딩될 지 장담할 수 없다. 사용해야 참조해서 올라옴. 엔진 단에 추가 라이브러리 금지. 엔진에있는 것 참조하게 됨.(wildfly도 마찬가지) /tomcat/apache-tomcat-8.5.53/lib /tomcat/domains/tc85_01/lib /tomcat/application/tc85_01/simplehome/WEB_INF/lib → 만일 내부 중복 라이브러리가 존재할 경우, 내부 클래스 엉키는 경우 발생 라이브러리 맞춰야 함 |
6. 장애 분석 실무 사례
| db병목 발생 사례 | # db병목 발생 사례 단 건 쿼리가 아니라 대량 건의 쿼리가 들어올 때 발생하는 병목현상은 단 건 쿼리 튜닝은 해결 x <대량 부하와 단건 쿼리 부하는 다름> 교육 사이트 메인 화면에 자잘하게 db불러오는 경우 → 디비까지 안가고 캐시화하여 해결 db connection 부족할 경우 ) db connection늘린다? 오히려 connection 개수 줄이고나서 퍼포먼스 부분을 잡아야함(5개 connection, 10개 connection, 20개 connection)
was 주요 기능 중 하나 : db보호 (client → (os(web)) → (os(was(application))) → DBMS) ⇒ db가 몇개까지 수용할 수 있는지/ was - 몇개를 해야 db퍼포먼스를 유지할 수 있는지 |
| 디비 공유 사례 | # 디비 공유 사례 - 아이폰 예판 8(일반고객) : 2(대리점) 대리점 막아버림(일반고객db터질 수 있으므로) 전체 시스템과 시나리오 고려해야만함, 대리점 증량x 오히려 악화 전체를 보고 협의나 포기를 해야했던 상황 db는 중요함, 무너지면 안됨 |
| web server 과부하 → was 영향 사례 | # 복합 현상 발생 “web server 과부하가 was에 영향을 끼치는 사례 web was가 같은 서버에 있을 경우, was메모리 부족으로 인해 web 서버 resource부족하는 경우도 있었음 ⇒ web was 서버 합쳐지지 않게끔, 솔루션 별도로, 메모리에 대한 확보 메모리 고려할 것 ⇒ 서버 전체에 대한 resource 상태 점검 필요 |
| ap에서 들고는 있는데 쿼리는 안던지고 connection만 열어두었던 사례 |
# ap에서 들고는 있는데 쿼리는 안던지고 connection만 열어두었던 상황 - transaction길게 갖고있는 경우 ap에서 db 쓰고 return안 된 경우 “ActiveCount” ⇒ 쿼리와 쿼리사이 갭차이가 많았음 (1) AP → DB ← (2) (1)과 (2) 쿼리 사이 간격이 점점 늘어남 이유 : db관련된 처리를 log로 남기고, result도 log로 남김 로그 처리는 직렬로 돼 있어서 줄이 생김 ⇒ 결국 아웃풋(traffic) 자체가 늦어짐 /idle section 많아보임 ⇒ log자체를 들어냄 Sync 방식의 로그 처리로 병목으로(logback → log4j v2) 변경 후 async 방식으로 일부 추가 result object 로그 출력 부분정리 (connection 증가의 원인) (client → (os(web)) → (os(was(application))) → DBMS) →외부시스템 Fact기반에 문제 가능성 고려 (AP와 논의 ) Gclog - pool gc가 잦은 떨어지는 시점이 문제 ⇒ 누적 but 단 건이 아니기에 AP clear정리되는 것을 찾아줘야함 lwp / thread dump 뽑아서 비교 |
| cpu 과다 사용 이슈 사례 | # 2023.02 cpu 과다 사용 이슈 object가 null이 아닌 경우 → object 지속적으로 생성 ⇒ 무한루프에 빠지면 cpu 잡아 먹으면서 내부 object 누적 ⇒ cpu도 튀고 메모리도 부족 <흐름인지 중요- cpu가 무엇이 다른지 등 > |
*문제를 추려가는 식으로 좁혀가는 것이 중요*
