GC 성능 고려 사항
GC에는 처리량(총 GC 시간 비율에 포함되지 않는 작업 시간)과 일시 중지(GC 발생 시 앱이 외부 디스플레이에 응답하지 못하는 상태)라는 두 가지 주요 성능 지표가 있습니다.
1. 총 힙
기본적으로 가상 머신은 전체 가상 머신의 여유 공간 비율을 유지하기 위해 힙 크기를 늘리거나 줄이며, 이 비율은 MinHeapFreeRatio 및 MaxHeapFreeRatio로 지정됩니다.
일반적으로 서버 측 앱에는 다음과 같은 규칙이 적용됩니다.
가급적 많은 메모리를 할당하고, VM에 최대한 많은 메모리를 할당하며, Xms와 Xmx를 동일한 값으로 설정합니다. VM 시작 설정에 사용된 메모리가 상대적으로 작으면 더 많은 개체를 초기화해야 할 때 VM이 메모리를 반복해서 추가해야 합니다.
프로세서 코어 수가 증가함에 따라 메모리도 증가합니다.
2. 젊은 세대
앱의 원활한 실행에 영향을 미치는 또 다른 요소는 젊은 세대의 크기입니다. 젊은 세대가 클수록 마이너 컬렉션이 줄어들지만, 힙 크기가 고정되어 있는 경우 젊은 세대가 크면 수명 세대가 작아져 메이저 컬렉션이 많아집니다(메이저 컬렉션이 마이너 컬렉션으로 이어짐).
NewRatio는 수명 세대 대비 하위 세대 크기의 비율을 반영하며, NewSize와 MaxNewSize는 하위 세대 크기의 하한과 상한을 반영합니다. 이 두 값을 같은 값으로 설정하면 젊은 세대의 크기가 고정됩니다(Xms 및 Xmx 설정과 동일).
서바이버 비율은 원하는 경우 생존자의 크기를 최적화할 수도 있지만 성능에는 거의 영향을 미치지 않으며, 서바이버 비율은 에덴과 생존자의 크기 비율입니다.
일반적으로 서버 측 앱에는 다음과 같은 규칙이 적용됩니다.
먼저 VM에 할당할 수 있는 최대 힙 크기를 결정한 다음 최적의 어린 세대 크기를 설정합니다.
힙 크기가 고정되어 있는 경우 젊은 세대의 크기를 늘리면 수명 세대의 크기가 줄어듭니다. 수명 세대는 모든 라이브 데이터를 항상 저장할 수 있을 만큼 충분히 크게 설정합니다(10~20%는 여유 공간으로 남겨둡니다).
경험 &; & 앰프 규칙
젊은 세대 크기 선택
우선 응답 시간 적용: 시스템의 최소 응답 시간 제한에 근접할 때까지 가능한 한 크게 설정합니다(적절히 선택). 이 경우 젊은 세대 수집 빈도도 최소화됩니다. 동시에 이전 세대에 도달하는 개체 수가 줄어듭니다.
처리량 우선 애플리케이션: 가능한 한 크게 설정합니다(최대 Gbit 수준까지). 응답 시간에 대한 요구 사항이 없으므로 일반적으로 8개 이상의 CPU를 사용하는 애플리케이션의 경우 병렬로 쓰레기 수집을 수행할 수 있습니다.
너무 작게 설정하지 마세요. 새 세대를 너무 작게 설정하면 다음과 같은 결과가 발생합니다.1. YGC 시간이 더 자주 발생합니다.2. YGC 객체가 이전 세대로 직접 이동할 수 있으며 이때 이전 세대가 가득 차면 FGC가 트리거됩니다.
이전 세대 크기 설정
응답 시간 우선 애플리케이션: 이전 세대는 동시 수집기를 사용하므로 일반적으로 동시 세션 속도, 세션 지속 시간 등의 일부 매개 변수를 고려한 크기로 신중하게 설정해야 합니다. , 세션 지속 시간 및 기타 몇 가지 매개 변수를 고려하여 신중하게 설정해야 합니다. 힙을 작게 설정하면 메모리 조각화, 빈번한 회수 및 애플리케이션 일시 중단이 발생할 수 있으므로 기존의 마크 앤 클린 방식이 사용되며, 힙이 크면 수집하는 데 시간이 오래 걸립니다. 최적의 솔루션은 일반적으로 다음과 같은 데이터를 참조하여 얻어야 합니다.
동시 쓰레기 수집 정보, 지속적 세대의 동시 수집 횟수, 기존 GC 정보, 젊은 세대와 오래된 세대 간의 재생에 소요되는 시간 비율.
처리량 우선 애플리케이션: 일반적으로 처리량 우선 애플리케이션은 젊은 세대 그룹이 많고 오래된 세대 그룹이 적습니다. 그 이유는 대부분의 단기 개체는 최대한 재활용할 수 있고, 중기 개체는 줄일 수 있으며, 오래된 세대는 장기적으로 살아있는 개체를 저장할 수 있기 때문입니다.
더 작은 더미로 인한 조각화 문제
구형 동시 수집기는 마크 앤 클리어 알고리즘을 사용하기 때문에 힙을 압축하지 않습니다. 수집기가 회수할 때 인접한 공간을 병합하여 더 큰 객체에 할당할 수 있도록 합니다. 그러나 힙 공간이 작으면 잠시 후 '조각화'가 발생합니다. 동시 수집기가 충분한 공간을 찾지 못하면 중지하고 기존의 마크 앤 클린 방법을 사용하여 재활용합니다.
-xx:+usecmscompactaftullcollection:동시 수집기를 사용할 때 이전 세대 압축을 켭니다.
-xx:cmsfullgcsbeforecompression = 0: 위 구성을 켤 때 이전 세대 압축을 사용하여 여기에 설정할 전체 GC 수는 몇 개입니까?
64비트 OS에서 Linux의 64비트 jdk는 32비트 jdk보다 느리지만 메모리를 더 많이 사용하고 처리량이 더 많습니다.
XMX는 XMS만큼 크도록 설정되고 MaxPermSize는 MinPermSize만큼 크도록 설정되므로 힙 크기 확장에 따른 부담이 줄어듭니다.
CMS 사용의 장점은 128m-256m의 경험적 값으로 가능한 한 적은 수의 새로운 세대를 사용하고, 오래된 세대는 CMS를 사용하여 병렬로 수집하므로 지연 시간이 짧고 시스템의 처리량 효율을 보장한다는 것입니다. 실제로 CMS의 수집 일시 중지 시간은 매우 짧으며 2G 메모리를 사용하면 애플리케이션 일시 중지 시간은 약 20-80ms입니다.
시스템이 중지되면 GC 문제이거나 프로그램 문제일 수 있습니다. jmap과 jstack 또는 killall -3 자바로 확인하고 자바 콘솔 로그를 확인하면 많은 문제를 확인할 수 있습니다. (관련 도구 사용 방법은 추후 블로그에서 설명하겠습니다.)
애플리케이션을 주의 깊게 이해하세요. 캐시를 사용하는 경우, 이전 세대는 더 커야 하고 캐시된 해시맵은 무제한이 아니어야 합니다. 캐시로 LRU 알고리즘 맵을 사용하는 것이 좋으며, LRUMap의 최대 길이는 실제 상황에 맞게 설정해야 합니다.
동시 재활용을 사용할 때 젊은 세대는 더 작고 오래된 세대는 더 크며, 오래된 세대는 동시 재활용을 사용하기 때문에 시간이 오래 걸리더라도 다른 프로그램이 계속 실행되는 데 영향을 미치지 않으며 웹 사이트가 중지되지 않습니다.
JVM 매개 변수(특히 -xmx-xms-xmn-xx:생존자 비율-xx:최대 지속 임계값)를 설정하는 고정된 공식은 없으며, PV 이전 영역의 실제 데이터를 기반으로 해야 합니다. YGC 카운트가 측정됩니다. 업그레이드 실패로 인해 xmn이 너무 작게 설정되어 YGC 수가 증가하고 동시 접속 처리 능력이 저하되는 문제를 피하기 위해서입니다. 각 파라미터를 조정하려면 특정 애플리케이션에 가장 적합한 구성을 찾기 위해 상세한 성능 테스트가 필요합니다.
프로모션 실패:
러비시 수집에서 프로모션 실패는 일반적으로 두 가지 이유로 인해 발생할 수 있는 골치 아픈 문제입니다. 첫 번째 이유는 구조 공간이 충분하지 않기 때문입니다. 구조 공간에 있는 물건은 이전 세대로 옮겨서는 안 되지만 젊은 세대는 구조 공간에 넣어야 하는 물건이 많기 때문입니다. 두 번째 이유는 구세대가 젊은 세대의 물체를 수용할 공간이 충분하지 않기 때문입니다. 두 경우 모두 전체 GC로 전환되고 사이트가 장시간 일시 중지됩니다.
해결 방법 1:
첫 번째 이유에 대한 최종 해결책은 구조 공간을 제거하고 -xx:survivorscale= 65536-xx:maxtenuringthreshold = 0으로 설정하는 것이었습니다. 두 번째 이유에 대한 해결책은 CMS의 개시점유율을 어떤 값(70으로 가정)으로 설정하여 구세대가 공간의 70%에 도달하고 구세대가 젊은 세대의 객체를 수용할 수 있는 충분한 공간을 확보할 때 CMS가 구현되도록 하는 것입니다.
솔루션 1에 대한 개선 사항:
다시 개선. 위의 방법은 구조 공간을 사용하지 않기 때문에 구세대가 꽉 차기 쉽고 CMS 구현이 더 자주 발생하기 때문에 그다지 좋지 않습니다. 나는 그것을 개선하여 여전히 구조 공간을 사용하지만 구조 공간을 늘 렸으므로 프로모션 실패가 없을 것입니다. 실제로 32 비트 리눅스와 64 비트 리눅스는 다른 것 같습니다. 64비트 시스템에 대해 MaxTenuringThreshold 매개 변수가 구성되어 있는 한 CMS가 여전히 일시 중지되는 것 같습니다. 일시 중지 및 부스트 실패 문제를 해결하기 위해 마침내 -XX:SurvivorRatio=1을 설정하고 MaxTenuringThreshold를 제거하여 일시 중지 및 부스트 실패가 발생하지 않도록 했으며, 또한 이전 및 영구 세대가 매우 느리게 상승하므로 (많은 개체가 이전 세대에 도달하기 전에 재활용되므로) CMS 실행이 매우 드물게, 몇 시간에 한 번씩만 실행됩니다.
-xmx 4000m-xms 4000m-xmn 600m-XX:PermSize = 500m-XX:MaxPermSize = 500m-XSS 256k-XX:+DisableExplicitGC-XX:survivor ratio = 1-XX:+ useconmarksweepgc-XX:+UseParNewGC-XX:+cmspallelremarkenabled-XX:+UseCMSCompactAtFullCollection-XX:cmsfullgcsbeforecompression = 0-XX :+cmssclassunloadingenabled-XX
CMS 시작 점유 분할 값 대 Xmn에 대한 방정식
부스팅 실패의 원인은 EDEN에 공간이 충분하지 않으면 EDEN의 생존 개체와 From survivor가 To 생존자 영역에 저장되고, 구세대 영역에 메모리가 부족하면 To 생존자 영역이 다시 구세대 영역으로 부스트되어 전체 GC가 발생하기 때문입니다. from survivor를 통해 Eden+
(Xmx-Xmn)*(1-CMS initiatingcoccupancyfraction/ 100)>= (xmn-xmn/(생존자+2))로 추론한 다음 다음과 같이 추정할 수 있습니다.
CMS 개시 점유 분할 & lt;=((Xmx-Xmn)-(Xmn-Xmn/(생존자 비율+2))/(Xmx-Xmn)* 100
예를 들어 :
xmx = 128 xmn = 36 생존자 = 1일 때, CMS 시작 OCCUNCYFRACTION < =((128.0-36)-(36-36/(1+2)))/(128-36)* 100 = 73.913
xmx = 128 xmn = 24일 때 생존자 = 1, 생존자 비율 = 1, 점유 효과 시작 < =((128.0-24)-(24-24/(1+2)))/(128-24)* 100 = 84.615...
xmx = 3000xmn = 생존자 비율 = 1일 때 시작 점유 효과
CMS 시작 점유 비율이 70% 미만인 경우 xmn 또는 생존자 값을 조정해야 합니다.