JVM 급 고 검사 스 크 립 트 - 구조 분석

이 글 은 알 리 바 바 기술 협회 (ATA) 특 선 글 에서 나 왔 다.온라인 프로그램 LOAD 가 갑자기 폭주 하 는 장면 을 본 적 이 있 습 니 다. 왜 폭주 하 는 지 알 아 내 는 것 이 급선무 입 니 다. CPU 가 치 솟 는 원인 을 찾 는 것 이 급선무 입 니 다.Nginx, Apache 등 프로 세 스 급 애플 리 케 이 션 이 라면 검색 이 용이 하지만 JVM 의 한 스 레 드 로 인 한 것 이 라면 누 군 가 는 헷 갈 릴 것 으로 보인다.
많은 사람들 이 이런 스 크 립 트 가 있다 는 것 을 알 고 있 습 니 다. 현장에서 LOAD 가 급증 하 는 JVM 스 레 드 를 대체적으로 찾 아 줄 수 있 습 니 다. 스 크 립 트 는 다음 과 같 습 니 다.

#!/bin/ksh

# write by    : [email protected]
# date        : 2014-01-16
# version     : 0.07

typeset top=${1:-10}
typeset pid=${2:-$(pgrep -u $USER java)}
typeset tmp_file=/tmp/java_${pid}_$$.trace

$JAVA_HOME/bin/jstack $pid > $tmp_file
ps H -eo user,pid,ppid,tid,time,%cpu --sort=%cpu --no-headers\
        | tail -$top\
        | awk -v "pid=$pid" '$2==pid{print $4"\t"$6}'\
        | while read line;
do
        typeset nid=$(echo "$line"|awk '{printf("0x%x",$1)}')
        typeset cpu=$(echo "$line"|awk '{print $2}')
        awk -v "cpu=$cpu" '/nid='"$nid"'/,/^$/{print $0"\t"(isF++?"":"cpu="cpu"%");}' $tmp_file
done

rm -f $tmp_file

이제 그 원 리 를 분해 하고 유사 한 스 크 립 트 의 적용 범 위 를 설명 하 겠 습 니 다.
STEP 1: 현재 JVM 스 레 드 를 덤 프 하고 현장 JAVAHOME / bin / jstack pid > $tmp 저장file 저장 현장 은 상당히 중요 합 니 다. 문제 가 순식간에 손 에서 빠 져 나 가기 때 문 입 니 다. (그러나 사실은 LOAD 의 통계 체제 도 결정 되 었 고 사실 도 그렇게 엄격 하지 않 습 니 다)
STEP 2: 현재 CPU 사용 비율 이 높 은 스 레 드 ps H - eo user, pid, ppid, tid, time,% cpu – sort =% cpu 찾기
alt
설명 을 열거 하 다
USER: 프로 세 스 귀속 사용자
PID: 프로 세 스 번호
PPID: 부모 프로 세 스 번호
TID: 스 레 드 번호
% CPU: 스 레 드 는 CPU 비례 를 사용 합 니 다. (이 CPU 비례 는 / proc 로 계산 되 며 시간 차 가 있 음 을 알려 드 립 니 다.)
STEP 3: 관련 정 보 를 통합 할 때 우리 가 주목 해 야 할 것 은 약 3 열 입 니 다. PID, TID,% CPU 입 니 다. 우 리 는 PS 를 통 해 TID 를 얻 었 습 니 다. 진법 으로 10 - 16 을 환산 하여 jstack 에서 나 온 JVM 스 레 드 번 호 를 얻 을 수 있 습 니 다.
typeset nid = "0x" (echo "line" | awk "{print $1}" | xargs - I {} echo "obase = 16; {}" | bc | tr "A - Z" a - z ") 마지막 으로 ps 와 jstack 에서 나 온 정 보 를 일치 시 킵 니 다. 드디어 우리 가 가장 원 하 는 정 보 를 얻 었 습 니 다.
alt
적용 범 위 는 이 스 크 립 트 가 매우 훌륭 해 보 이 는 X 의 모습 을 설명 합 니 다. CPU 가 가장 많이 소모 되 는 스 레 드 를 직접 찾 을 수 있 습 니 다. 개발 은 더 이상 온라인 에서 가장 문제 가 있 는 코드 를 찾 을 수 없 을 까 봐 걱정 하지 않 아 도 됩 니 다 ~ 하지만, 잠시 만 요. 출력 결 과 를 주의 하 세 요. State: WAITING 이게 무슨 리듬 입 니까 ~
alt
이것 은 ps 의% CPU 데이터 통 계 는 / proc / stat 에서 나 온 것 입 니 다. 이 데 이 터 는 실시 간 이 아니 라 OS 가 업데이트 하 는 빈도 에 달 려 있 습 니 다. 일반적으로 1S 입 니 다. 따라서 보 이 는 데이터 통 계 는 jstack 에서 나 온 정보 와 일치 하지 않 습 니 다. 바로 이 때 문 입 니 다 ~ 그러나 이 정 보 는 지속 적 인 LOAD 가 몇 개의 스 레 드 로 인해 발생 하 는 문제 에 대한 조사 에 매우 힘 이 됩 니 다. 이러한 고정 적 인 정보 때문에몇몇 스 레 드 는 CPU 의 자원 을 지속 적 으로 소모 합 니 다. 시간 차이 가 있 더 라 도 어차피 이 몇 개의 스 레 드 로 인해 발생 합 니 다.
타 오 바 오 내부 에서 자주 찾 아 볼 수 있 는 몇 가지 문제 스 레 드 를 공유 합 니 다. 사용 하 다가 LOAD 가 갑자기 높 아 지면 먼저 의심 할 수 있 습 니 다.
Forest、CatServer、Notify
다음으로 이동:http://yq.aliyun.com/articles/55