JVM 매개변수 튜닝 사례 분석

원본 출처:

JVM 매개변수 튜닝과 관련해 많은 프로그래머들에게 골치 아픈 문제는 설정이 좋지 않으면 JVM이 계속해서 Full GC를 실행하게 되어 전체 시스템이 매우 느려지고 웹 사이트가 느려지는 원인이 됩니다. 10초 이상 지속될 수도 있습니다. 몇 분마다 이런 일이 발생하면 견딜 수 없습니다.

이러한 정체는 테스트 중에는 볼 수 없습니다. 웹사이트 PV가 수십만/일에 도달할 때만 문제가 드러납니다. JVM 매개 변수를 구성하려면 젊은 세대, 구세대, 구조 공간 및 당신을 이해해야 합니다. 영구 생성에 대해 어느 정도 이해하고 JVM 메모리 관리 논리도 이해해야 하며 궁극적으로 자신의 애플리케이션에 따라 조정해야 합니다. 인터넷에서 검색하면 JVM 매개변수를 많이 찾을 수 있고, 실제적인 예제도 많이 있습니다. 또한 다양한 예제를 테스트했지만 몇 달간 연습하고 개선한 후에는 결국 문제가 발생하게 됩니다(요구 사항 없음). ) jvm 매개변수(데드타임) 튜닝을 위해 다음과 같은 경험이 제공됩니다.

1: 64비트 운영 체제를 사용하는 것이 좋습니다. Linux에서 64비트 JDK는 32비트 JDK보다 느리지만 더 많은 메모리를 소비하고 처리량이 더 높습니다.

2: XMX 및 XMS 설정은 크기가 동일하고 MaxPermSize 및 MinPermSize 설정은 크기가 동일하므로 힙 크기 조정으로 인한 압력을 줄일 수 있습니다.

3: 디버깅 중에 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log와 같은 일부 인쇄 매개변수를 설정하여 gc에서 볼 수 있습니다. 로그 몇 가지 단서를 생각해 보세요.

4: 시스템이 일시 중지되면 GC 문제이거나 프로그램 문제일 수 있습니다. Jmap 및 Jstack을 사용하여 확인하거나 killall -3 Java를 사용한 다음 Java 콘솔 로그를 확인하면 많은 문제를 볼 수 있습니다. 한번은 웹사이트가 갑자기 엄청 느려졌는데, Jstack이 확인해 보니, 직접 작성한 URL Connection이 너무 많아 공개가 안 되는 것 같았고, 프로그램을 바꿔보니 괜찮더군요.

5: 애플리케이션을 주의 깊게 이해하세요. 캐싱된 HashMap은 무한히 길어서는 안 됩니다. LRUMap의 최대 길이도 길어야 합니다. 실제 상황을 바탕으로 구성되었습니다.

6: 승격 실패는 가비지 수집 중에 매우 골치 아픈 문제입니다. 일반적으로 두 가지 이유로 발생할 수 있습니다. 첫 번째 이유는 구조 공간에 있는 개체를 이전 세대로 이동해서는 안 된다는 것입니다. 그러나 Young Generation은 Rescue 공간에 넣어야 할 객체가 많습니다. 두 번째 이유는 Old Generation이 Young Generation의 객체를 받아들일 공간이 충분하지 않기 때문입니다. 웹사이트 일시 정지 시간이 길어집니다. 첫 번째 이유에 대한 최종 해결책은 복구 공간을 제거하고 -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0을 설정하는 것입니다. 두 번째 이유에 대한 해결책은 CMSInitiatingOccupancyFraction을 특정 값(70으로 가정)으로 설정하는 것입니다. , CMS는 Old Generation 공간이 70%에 도달하면 실행되며, Old Generation은 Young Generation의 개체를 수용할 수 있는 충분한 공간을 갖게 됩니다.

7: 어쨌든 영구 생성은 점차 가득 차기 때문에 매일 3~5회마다 Java 서버를 다시 시작해야 합니다.

8: 동시 재활용을 사용할 때 Young 세대는 더 작아야 하고 Old 세대는 더 커야 합니다. Old 세대는 동시 재활용을 사용하기 때문에 시간이 오래 걸리더라도 다른 프로그램의 지속적인 운영에 영향을 미치지 않으며, 저의 최종 결과는 다음과 같습니다(시스템 8G 메모리). 매일 수백만 PV가 문제없이 작동하며, 2009년에도 메모리 문제로 인해 웹사이트가 다운되지 않았습니다.

2. $JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M

4. -XX:MaxPermSize=500M -XX :SurvivorRatio=

   65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC

6. -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX: +UseCMSCompactAtFull 컬렉션

8. -XX:CMSFullGCsBeforeCompaction=

   0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled

10. -XX:CMSInitiatingOccupancyFraction=

    90 -XX:Soft RefLRUPolicyMS PerMB=0 -XX:+PrintClassHistogram

12. -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log ";

설명, -XX:SurvivorRa ti o=65536 - XX:MaxTenuringThreshold=0은 복구 공간이 제거되었음을 의미합니다.

◆-Xnoclassgc는 가비지 수집을 비활성화하고 성능은 더 높아집니다.
◆-XX:+DisableExplicitGC는 프로그래머가 실수로 호출하는 것을 방지하기 위해 System.gc()를 비활성화합니다. gc 방법 및 성능에 영향을 미칩니다.
◆-XX:+UseParNewGC는 젊은 세대를 위한 다중 스레드 병렬 재활용을 사용하므로 CMS 매개변수는 동시 재활용과 관련됩니다.

CMSInitiatingOccupancyFraction

이 매개변수를 설정하는 데는 많은 기술이 필요합니다. 기본적으로 (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn이면 승격 실패가 없습니다. 내 애플리케이션에서 Xmx는 6000이고 CMS(Concurrent Garbage Collection), 이때 남은 10% 공간은 5500*10%=550MB이므로 Xmn에 있는 모든 객체(즉, 총 500MB)가 Young Generation)은 Old Generation, 550MB로 이동됩니다. 충분한 공간이 있으므로 위 공식이 충족되는 한 가비지 수집 중에 승격 실패가 발생하지 않습니다.

SoftRefLRUPolicyMSPerMB

이 매개 변수는 공식적인 설명은 소프트 접근 가능 개체가 마지막 참조 이후 일정 시간 동안 활성 상태로 유지된다는 것입니다. 기본값은 힙의 여유 메가바이트당 1초입니다. 1초만 기다리세요.

인터넷에는 JVM 매개변수에 대한 소개가 많이 있습니다. 승격 실패를 경험하지 않았거나 방문 횟수가 너무 적어 만날 기회가 없는 경우가 대부분인 것으로 추정됩니다. , 공식 (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn은 확실히 독창적입니다. 실제로 Promotion Failed가 발생하면 이 방법으로 처리해야 합니다.

위 내용은 JVM 매개변수 튜닝 사례 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!