이 기사는 일부 온라인 문제의 분석 및 해결에 대해 설명하며 스레드 문제가 너무 많고 너무 이상하기 때문에 기본 작업으로 제한되며 큰 사람도 어려운 문제에 직면하게 됩니다. 더 중요한 것은 집주인으로서 내 수준이 제한적이라는 것입니다. . . 나는 내 자신의 경험과 내가 듣고 본 것을 요약 할 수 있으며 문제에 직면했을 때 아이디어가 있기를 바랍니다.
Java 프로그래머의 경우 온라인 문제 해결은 불가피합니다. 나는 종종 신발을 적시지 않고 강가를 걷는다. 갑자기 높은 CPU, 메모리 오버플로, 빈번한 GC, 시스템 정지 및 기타 유사한 문제에 직면했습니다. 우리는 무엇을 해야 합니까? 이러한 문제를 해결하는 방법은 무엇입니까?
우선 문제가 발생하면 먼저 문제를 찾아낸 다음 문제의 원인을 분석한 다음 문제를 해결하고 마지막으로 다음 번에 다시 발생하지 않도록 요약해야 합니다.
Java 서비스에 대한 자주 묻는 질문
온라인 문제에 초점: CPU, 메모리
서버 문제 해결 명령: top 명령은 CUP에 초점을 맞추고, free 명령은 메모리에 초점을 맞춥니다.
참고: 내 환경 문제로 인해 스크린샷이 없으며 다음 스크린샷은 네트워크 스크린샷입니다.
1. CPU가 치솟고 있다
온라인 CPU 급등은 일반적인 문제여야 합니다.
아이디어: 먼저 CPU가 급등하는 Java 프로세스를 찾은 다음 이 프로세스에서 가장 높은 점유율을 가진 Java 스레드를 찾고 마지막으로 이 스레드의 스택 정보에 따라 문제 코드를 찾습니다. , 그런 다음 코드를 확인하여 문제를 해결하십시오.
작동하다:
- top 명령은 CPU 사용량이 가장 높은 Java 프로세스를 찾고
각 프로세스의 CPU 사용량을 높은 순서로 표시합니다. Load Average는 지난 1분, 5분, 15분 동안 시스템의 평균 부하를 보여주며 위 그림의 값은 2.46, 1.96, 1.99입니다.
| 상표 | 소개 |
|---|---|
| PID | 프로세스 ID |
| 사용자 | 프로세스 소유자 |
| 홍보 | 프로세스 소유자 |
| 안에 | 좋은 가치. 음수 값은 높은 우선 순위를 나타내고 양수 값은 낮은 우선 순위를 나타냅니다. |
| VIRT | 프로세스에서 사용하는 가상 메모리의 총량(kb)입니다. VIRT=스왑+RES |
| RES | 프로세스에서 사용하고 스왑 아웃되지 않은 물리적 메모리 크기(kb)입니다. RES=코드+데이터 |
| SHR | 공유 메모리 크기, 단위 kb |
| 에스 | 프로세스 상태. D=무정전 절전 R=실행 S=휴면 T=추적/중지 Z=좀비 프로세스 |
| %CPU | 마지막 업데이트 이후 CPU 시간의 % |
| %메모리 | 프로세스에서 사용하는 물리적 메모리의 백분율 |
| 시간 + | 프로세스에서 사용한 총 CPU 시간(1/100초 단위) |
| 명령 | 프로세스 이름 |
여기에서 우리는 CPU 사용량이 가장 높은 Java 프로세스의 PID가 11506임을 발견했습니다.
2. ps -mp pid -o THREAD,tid,time 명령을 사용하여 프로세스 11506에서 CPU 사용량이 가장 높은 스레드를 찾습니다.
위 그림에서 CPU 사용량이 가장 높은 스레드가 11508이라는 것을 알 수 있습니다. Convert 11508 16진수
형식이므로(Java 네이티브 스레드는 16진수 형식으로 출력되므로) printf "%x\n" 11508을 사용하여 16진수 형식으로 변환한 다음 jstack -l 11508>jstack.log를 사용할 수 있습니다
. 스레드의 스택 정보를 로그 파일에 덤프한 다음 방금 스레드 ID의 16진수 코드를 사용하여 스택 로그 파일을 분석하여 특정 비즈니스에서 무한 루프가 발생했는지 확인합니다.내 친구는 전자 상거래 회사입니다. 교착 상태에 대해 가장 많이 이야기한다고 들었습니다. 따라서 이런 종류의 문제가 발생하면 먼저 시스템에 교착 상태가 있는지 확인할 수 있습니다.
교착 상태가 없다면 미친 GC가 있는지 확인하십시오.HttpClient를 통해 타사 서비스에 액세스하여 CPU가 급증한 남동생이 있습니다.그들의 HttpClient는 시간 초과 기간을 설정하지 않았으며 여전히 개체를 생성하고 있습니다. 결과적으로 jvm은 GC를 유지하고 CPU를 한계까지 푸시합니다. . CPU 폭등이 반드시 어떤 이유에 의한 것은 아니며 지수는 원인을 분석하기 위해 일반적인 방법을 마스터해야 함을 알 수 있습니다.
2. 메모리 문제 해결
위에서 말한 것은 CPU가 치솟고 있다는 것이고, 가장 큰 이유는 우리가 스스로 파낸 구덩이 때문입니다.
우리가 말하는 메모리 문제는 보통 GC 문제입니다
.두 가지 상황이 있는데, 하나는 메모리가 넘치는 경우이고 다른 하나는 메모리가 넘쳐나지 않지만 GC가 건강하지 않은 경우입니다.
메모리 오버플로우의 경우 -XX:+HeapDumpOnOutOfMemoryError 매개변수를 추가할 수 있으며, 이 매개변수의 기능은 프로그램 메모리 오버플로우 시 덤프 파일을 출력하는 것입니다.
덤프 파일을 사용하면 일반적으로 사용되는 MAT, Jprofile, jvisualvm 및 기타 도구와 같은 덤프 분석 도구로 분석할 수 있습니다. 이러한 도구는 어디에서 오버플로가 발생하는지, 많은 수의 개체가 생성되는 위치 등을 확인할 수 있습니다.
두 번째 상황은 더 복잡합니다. GC는 비정상입니다.
건강한 GC
YGC는 5초에 한 번 정도이며 각 시간은 50밀리초를 초과하지 않습니다. FGC를 하지 않는 것이 가장 좋으며 CMS GC는 하루에 한 번 정도입니다.
GC 최적화에는 두 가지 차원이 있습니다. 하나는 빈도이고 다른 하나는 기간입니다.
YGC부터 보자면 먼저 주파수를 보자면 YGC가 5초 이상이거나 그 이상이면 시스템 메모리가 너무 커서 용량을 줄여야 한다는 뜻이고, 주파수가 높다면 Eden 영역이 너무 작아서 Eden 영역을 늘릴 수 있지만 전체 생성 용량은 힙의 30% - 40% 사이여야 하고 Eden, from 및 to의 비율은 약 8:1:1이어야 하며, 이 비율은 개체 프로모션의 크기에 따라 조정될 수 있습니다.
YGC가 너무 오래 걸린다면? YGC에는 두 가지 프로세스가 있는데 하나는 스캐닝이고 다른 하나는 복사입니다.일반적으로 스캔 속도는 매우 빠르고 복사 속도는 상대적으로 느립니다.매번 복사할 객체가 많으면 STW 시간이 길어집니다. . 상황은 StringTable입니다. 이 데이터 구조는 String.intern 메소드에서 반환된 상수 연결 풀의 참조를 저장합니다. YGC는 이 데이터 구조(HashTable)를 매번 스캔합니다. 긴 STW 기간, 또 다른 상황은 가상입니다. 운영 체제의 메모리, GC가 우연히 운영 체제가 메모리를 교환하는 경우 STW 기간도 길어집니다.
FGC를 다시 살펴보자면, 사실 FGC의 빈도만 최적화할 수 있지만 지속 시간은 제어할 수 없기 때문에 지속 시간은 최적화할 수 없습니다. 빈도를 최적화하는 방법은 무엇입니까?
우선 FGC를 하는 이유는 여러 가지가 있는데, 1은 Old 영역의 메모리 부족, 2는 메타데이터 영역의 메모리 부족, 3은 System.gc(), 4는 jmap 또는 jcmd, 5는 CMS 프로모션 실패 또는 동시 모드 실패, 6은 JVM 비관적 전략에 따라 YGC 이후 Old District는 승격 후보자를 수용하지 못하므로 YGC가 취소되고 FGC가 진행됩니다.
일반적인 최적화 포인트는 Old 영역의 메모리가 FGC를 발생시키기에 충분하지 않다는 것입니다. FGC 후에도 여전히 개체 수가 많다면 Old 영역이 너무 작다는 것을 의미하고 Old 영역을 확장해야 함을 의미하고 FGC 이후에 효과가 좋다면 수명이 짧은 개체가 많다는 것을 의미합니다. Old 영역의 객체들.최적화의 포인트는 이 객체들이 new generation에서 YGC가 되도록 하는 것임 일반적인 방법은 new generation을 늘리는 것임.크고 수명이 짧은 객체가 있을 경우 매개 변수를 통해 객체의 크기를 설정함 이러한 오브젝트가 Old 영역에 들어가는 것을 방지하기 위해 프로모션 연령이 너무 어린지 여부도 확인해야 합니다. YGC 이후 많은 수의 오브젝트가 서바이버 영역에 진입할 수 없어 조기에 승격된다면 서바이버 영역을 늘려야 하지만 너무 크면 안 된다.
위의 내용은 모두 최적화 아이디어이며 GC 상태를 알 수 있는 도구도 필요합니다.
JDK는 jmap, jcmd 등과 같은 많은 도구를 제공합니다. jcmd는 실제로 jmap의 많은 기능을 대체할 수 있기 때문에 Oracle은 공식적으로 jmap 대신 jcmd를 사용할 것을 권장합니다. jmap은 객체의 분포 정보를 인쇄할 수 있고, 파일을 덤프할 수 있습니다.jmap과 jcmd는 파일을 덤프할 때 FGC를 트리거하므로 사용 시 장면에 주의하십시오.
일반적으로 사용되는 또 다른 도구는 eden, from, to, old 및 기타 영역의 메모리 사용량과 같은 GC의 자세한 정보를 볼 수 있는 jstat입니다.
또 다른 도구는 jinfo로, 현재 jvm이 어떤 매개변수를 사용하고 있는지 확인할 수 있고 매개변수를 멈추지 않고 수정할 수도 있습니다.
덤프 파일, MAT, Jprofile, jvisualvm 등을 분석하기 위해 위에서 언급한 일부 시각화 도구를 포함합니다. 이러한 도구는 jmap에 의해 덤프된 파일을 분석하여 어떤 개체가 더 많은 메모리를 사용하는지 확인하고 일반적으로 문제를 찾을 수 있습니다.
还有很重要的一点就是，线上环境一定要带上 GC 日志！！！
온라인에는 복잡하고 복잡한 문제가 많아 한두 개의 기사로 다룰 수 없습니다.우리가 숙달해야 할 것은 방법입니다.올바른 방법을 사용하면 어떤 문제가 발생하든 아이디어를 얻을 수 있으며 약간의 경험이 매우 중요합니다. 문제를 만나 해결한 후 요약을 작성하십시오.
모든 유인원 별이 온라인에 접속하여 버그가 적기를 바랍니다.