la dimensione massima del mucchio java, quanto è troppo

Ho problemi con un'applicazione JRuby (rail) in esecuzione in tomcat. Occasionalmente, le richieste di pagine possono richiedere fino a un minuto per tornare (anche se i registri di binari hanno elaborato la richiesta in pochi secondi, quindi è ovvio un problema di tomcat).

Mi chiedo quali sono le impostazioni ottimali per la dimensione del mucchio di java. So che non esiste una risposta definitiva, ma ho pensato che forse qualcuno potrebbe commentare la mia installazione.

Sono su una piccola istanza EC2 che ha 1.7g ram. Ho i seguenti JAVA_OPTS:

-Xmx1536m -Xms256m -XX:MaxPermSize=256m -XX:+CMSClassUnloadingEnabled 

Il mio primo pensiero è che Xmx sia troppo alto. Se ho solo 1.7gb e ho assegnato 1.5gb a java, mi sento come se avrò un sacco di paging. Tipicamente il mio process java mostra (nella parte superiore) 1.1g res memory e 2g virtuale.

Ho anche letto da qualche parte che l'impostazione di Xms e Xmx alla stessa dimensione aiuterà in quanto elimina il tempo speso per l'allocazione della memory.

Non sono una persona java, ma sono stato incaricato di capire questo problema e cerco di sapere da where cominciare. Qualsiasi suggerimento è molto apprezzato !!

aggiornare
Ho iniziato ad analizzare le discariche per la raccolta di rifiuti utilizzando -XX:+PrintGCDetails

Quando noto questi periodi di carico lunghi occasionali, i log di gc vanno dadi. l'ultima che ho fatto (che ha preso 25s per completare) ho avuto gc linee di log come:

 1720.267: [GC 1720.267: [DefNew: 27712K->16K(31104K), 0.0068020 secs] 281792K->254096K(444112K), 0.0069440 secs] 1720.294: [GC 1720.294: [DefNew: 27728K->0K(31104K), 0.0343340 secs] 281808K->254080K(444112K), 0.0344910 secs] 

circa 300 di loro su una sola richiesta !!! Ora, non capisco completamente perché è sempre GC'ng da ~ 28m fino a 0 più e più volte.

  • Mancanti registri - Tomcat 5.5 + Ubuntu 8.04
  • Come posso impostare Tomcat con SSL su iSeries?
  • Tomcat 5.5: come redirect l'output di logging a un file per applicazione web
  • Tomcat configuration host virtuale
  • 4 Solutions collect form web for “la dimensione massima del mucchio java, quanto è troppo”

    Mentre non ho eseguito alcuna applicazione JRuby su Tomcat, ho eseguito applicazioni ColdFusion su diversi server J2EE app e ho anche avuto problemi simili.

    In queste domande frequenti , vedrai che SOracle dice che su Windows a 32 bit sarai limitato ad una dimensione massima di 1,4 a 1,6 GB. Non ho mai potuto farlo stabile in alto, e sospetto che stai eseguendo una configuration simile.

    La mia ipotesi è che le tue richieste richiedono molto tempo per eseguire b / c con una dimensione di heap alta, il JVM ha assegnato più memory fisica di quanto Windows wheresse dare e quindi Windows trascorre molto tempo a scambiare pagine dentro e fuori memory a disco in modo da poter fornire la quantità di memory richiesta al JVM.

    La mia raccomandazione, anche se counter-intuitiva, sarebbe che effettivamente ridurre la dimensione massima del mucchio da qualche parte intorno a 1,2 GB. È ansible aumentare anche la dimensione min, se si nota che sono in corso rallentamenti nell'elaborazione delle richieste dell'apparecchio mentre il JVM deve chiedere a Windows di aumentare la memory per aumentare la dimensione del suo mucchio quando si riempie di oggetti non raccolti.

    Parte del tuo problema è che stai probabilmente affamando tutti gli altri processi per ram. La mia regola generale per -Xms e -Xmx sono i seguenti:

    -Xms : <System_Memory>*.5
    -Xmx : <System_Memeory>*.75

    Così su un sistema da 4 GB sarebbe: -Xms2048m -Xmx3072m , e nel tuo caso vorrei andare con -Xms896m -Xmx1344

    in aggiunta alle risposte precedenti, si dovrebbe anche prendere in considerazione PermGen. PermGen non fa parte dell'heapspace. con la tua configuration corrente il tuo process java potrebbe riassumere fino a 1792mb che è la quantità totale della macchina.

    So che c'è già una risposta scelto, ma ancora, qui va la mia spiegazione.

    Prima di tutto, nella row di command che utilizzi, hai già riservato 1536 megabyte per l'heap di Java (-Xmx1536m) e 256 megabyte per PermGen (-XX: MaxPermSize = 256m). PermGen viene assegnato separatamente dall'heap di Java e viene utilizzato per memorizzare le classi Java caricate nel JVM.

    Queste 2 aree insieme già aggiungono fino a 1792 megabyte di RAM.

    Ma, oltre a ciò, c'è anche la RAM necessaria per caricare il JVM stesso (il codice nativo del JVM) e la RAM per memorizzare il codice generato dal compilatore JIT.

    Sospetto che tutti coloro che addizionano i 2 gigabyte virtuali che hai citato.

    Infine, wherete anche prendere in considerazione le altre cose che sono in esecuzione sul server e che hanno bisogno anche di RAM. Non hai parlato di quanto il swap sia in uso sul server. Questo ti dirà se la macchina sta scambiandosi e che sta causando l'applicazione a reactjs lentamente. Dovresti impedire in each momento la JVM di colpire lo swap. È molto meglio avviare frequentemente il collettore di rifiuti, piuttosto che assegnare troppi mucchi e far parte del mucchio di Java che viene sostituito.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.