Puncte:0

Heap mare Java în mediul container

drapel uy

Încerc să rulez un server web Jetty pe kubernetes, are nevoie de o cantitate extrem de mare de heap ~ 250 GB în mediul nostru de producție, ~ 50 GB în mediul nostru de testare.

eu folosesc debarcader:9.4-jdk11, încerc să evit setarea Xms sau Xmx semnalează în mod explicit, deoarece valoarea este diferită între diferite medii, pentru asta m-am gândit în funcție de -XX:MaxRAMPercentage -XX:InitialRAMPercentage ar fi mult mai bine, dar indiferent ce aș încerca, nu pot obține MaxHeapSize pentru a depăși 32178700288 ~ 30 GB.

Node, care are doar aplicația Java cu câteva sidcar-uri minuscule, are 64 GB de memorie.

Dockerfile

DE LA debarcader: 9.4-jdk11

ENV APP_WAR root.war
ENV APP_EXPLODED_WAR root/
ENV APP_DESTINATION_THE $JETTY_BASE/webapps/
ENV APP_DESTINATION_WAR $APP_DESTINATION_PATH$APP_WAR
ENV APP_DESTINATION_EXPLODED_WAR $APP_DESTINATION_PATH$APP_EXPLODED_WAR

ADĂUGA . $APP_DESTINATION_EXPLODED_WAR

ENV JAVA_OPTIONS -XX:+PrintFlagsFinal -XX:MaxRAMPercentage=90 -XX:InitialRAMPercentage=90 -XX:-OmitStackTraceInFastThrow -XX:+UseStringDeduplication -Xlog:gc*,stringdedup*=debug:file=/tmptime/g

Setările resurselor containerului

resurse:
  limite:
    CPU: "8"
    memorie: 60G
  cereri:
    CPU: "6"
    memorie: 60G

Pe baza acestor valori, ar trebui să obțin 90% din 60 GB MaxHeapSize ~ 54 GB, nu 30 GB. Ai idee ce îmi lipsește?

drapel in
Ați confirmat că variabila de mediu `JAVA_OPTIONS` este de fapt aplicată (adică vedeți rezultatul acelui `PrintFlagsFinal` în jurnale)?
drapel uy
Da, îl văd și pot confirma că este aplicat.
Puncte:0
drapel uy

Un argument JVM numit -XX:+UtilizațiCompressedOops care este activat implicit pe Java 11, este cauza, de la documentație.

-XX:-UtilizațiCompressedOops
    
Dezactivează utilizarea pointerelor comprimate. În mod implicit, această opțiune este activată, iar pointerii comprimați sunt utilizați atunci când dimensiunile heap Java sunt mai mici de 32 GB. Când această opțiune este activată, referințele la obiecte sunt reprezentate ca decalaje de 32 de biți în loc de pointeri de 64 de biți, ceea ce crește de obicei performanța atunci când rulează aplicația cu dimensiuni de heap Java mai mici de 32 GB. Această opțiune funcționează numai pentru JVM-uri pe 64 de biți.
    
De asemenea, este posibil să utilizați pointeri comprimați atunci când dimensiunile heap Java sunt mai mari de 32 GB. Consultați opțiunea -XX:ObjectAlignmentInBytes.

Doar în schimbare -XX:+ la -XX:- așa cum se arată mai sus, îl va dezactiva.

Folosind -XX:ObjectAlignmentInBytes nu este recomandat nici in cazul meu, din acelasi documentație.

-XX:ObjectAlignmentInBytes=aliniere

Setează alinierea memoriei obiectelor Java (în octeți). În mod implicit, valoarea este setată la 8 octeți. Valoarea specificată ar trebui să fie o putere de 2 și trebuie să fie în intervalul 8 și 256 (inclusiv). Această opțiune face posibilă utilizarea indicatoarelor comprimate cu dimensiuni mari de heap Java.

Limita de dimensiune a heap-ului în octeți este calculată astfel:

4 GB * ObjectAlignmentInBytes

Notă:

Pe măsură ce valoarea de aliniere crește, crește și spațiul nefolosit dintre obiecte. Ca rezultat, este posibil să nu realizați niciun beneficiu din utilizarea pointerilor comprimați cu dimensiuni mari de heap Java.

Dar cred că merită testat.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.