JVM 최적화는 몇 시간 동안 논의될 수 있습니다. 여기서는 체계적인 세부 사항을 다루지 않고 몇 가지 간단한 의견을 제시하겠습니다.
먼저 문제는 전체 GC가 빈번하다는 것입니다. 전체 메모리와 Old Generation 설정이 너무 작은지 확인하세요. 주로 -Xmx 및 -Xmn 매개변수에 따라 달라집니다. 너무 작으면 필연적으로 gc가 자주 발생합니다.
두 번째: 다음 매개변수 추가 -verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX: +PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails gc 때마다 Old Generation에 남은 공간, 일반적으로 말하면 공간을 확인합니다. Old Generation에서는 gc 이후 메모리의 2~2.5배로 설정하는 것이 더 합리적인 값입니다. 동시에 새로운 세대에서는 충분한 GC 없이 많은 수의 객체가 Old 세대로 들어가는지 여부를 이 로그를 통해 확인할 수 있습니다. New Generation을 통해 재활용이 가능한 객체가 Old Generation으로 들어가면 필연적으로 Full GC가 자주 발생하게 됩니다
셋째: 코드 이유 덤프 메모리 jmap -dump:live,format=b,file=xx.bin [pid] 그런 다음 MAT(http://www.eclipse .org/mat/) 어떤 대용량 메모리가 출시되지 않았는지 확인하는 도구
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
최적화되지 않았지만. 하지만 이를 최적화하기 위해서는 실제 비즈니스 요구와 비즈니스 역량을 기반으로 지원해야 한다고 생각합니다.
Java 애플리케이션의 힙 크기와 qps를 살펴보는데 처음에는 20분마다 Full gc를 보면 정상적이지 않은 것 같습니다
JVM 최적화는 몇 시간 동안 논의될 수 있습니다. 여기서는 체계적인 세부 사항을 다루지 않고 몇 가지 간단한 의견을 제시하겠습니다.
먼저 문제는 전체 GC가 빈번하다는 것입니다. 전체 메모리와 Old Generation 설정이 너무 작은지 확인하세요.
주로 -Xmx 및 -Xmn 매개변수에 따라 달라집니다. 너무 작으면 필연적으로 gc가 자주 발생합니다.
두 번째: 다음 매개변수 추가
-verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX: +PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails
gc 때마다 Old Generation에 남은 공간, 일반적으로 말하면 공간을 확인합니다. Old Generation에서는 gc 이후 메모리의 2~2.5배로 설정하는 것이 더 합리적인 값입니다.
동시에 새로운 세대에서는 충분한 GC 없이 많은 수의 객체가 Old 세대로 들어가는지 여부를 이 로그를 통해 확인할 수 있습니다. New Generation을 통해 재활용이 가능한 객체가 Old Generation으로 들어가면 필연적으로 Full GC가 자주 발생하게 됩니다
셋째: 코드 이유 덤프 메모리
jmap -dump:live,format=b,file=xx.bin [pid]
그런 다음 MAT(http://www.eclipse .org/mat/) 어떤 대용량 메모리가 출시되지 않았는지 확인하는 도구