Qual è lo spazio heap Java massimo per SuSE Linux

Question

Questa domanda è correlata a Java si rifiuta di avviarsi: non è stato possibile riservare spazio sufficiente per l'heap degli oggetti e dovrebbe essere abbastanza facile da capire.Tuttavia;le mie ricerche non hanno prodotto nulla di utile.

Essenzialmente abbiamo 2 sistemi operativi a 32 bit (RedHat e SuSE) su macchine diverse con lo stesso hardware.Entrambi utilizzano la stessa JVM eseguendo entrambi la stessa riga di comando.RedHat funziona perfettamente ma SuSE segnala che non c'è memoria sufficiente.

Dobbiamo solo sapere se si tratta di una limitazione della versione di SuSE che stiamo utilizzando o se si tratta di qualcos'altro.

'cat /proc/version' ci dà:

Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

'uname -a' ci fornisce quanto segue su ENTRAMBI i tipi di macchine:

UTC 2005 i686 i686 i386 GNU/Linux

Answer 1

Il limite di memoria JVM è legato il più grande libero contiguo di blocco a disposizione, non la quantità di memoria libera. Il limite varia da circa 1,4 GB a un po 'più di 2.0 GB, e dipende da dove il sistema operativo mette varie cose in memoria. Non conosco i particolari di dove roba carico RedHat o Suse in memoria, ma potrebbe essere che SUSE è la mappatura qualche libreria ad un indirizzo nel centro di RAM, dove Redhat potrebbe mappare alla fine (speculare).

E ricordate che l'uso effettivo della memoria in Java è più di quello specificato per Xmx. Le altre impostazioni della memoria influenzano anche la dimensione della vostra heap (come PermGen). Quindi potrebbe anche essere che lo spazio perm su Suse ha un valore predefinito larget che su RedHat.

Inoltre, a seconda del profilo di allocazione di memoria della vostra applicazione, si potrebbe ottenere via con una dimensione di heap più piccole e diverse opzioni di raccolta dei rifiuti. Ci sono alcuni dettagli qui ( http://java.sun.com/performance/ di riferimento / whitepaper / tuning.html ) e in altri luoghi. Ad esempio, se si alloca un sacco di piccoli, blocchi temporanei, si vorrà diverse impostazioni GC che se si hanno un sacco di bit, oggetti longevi.

Per quanto riguarda la questione legata, perché non basta usare RedHat? Che potrebbe essere una soluzione semplicistica, ma vi garantisco che sta andando a risolvere il problema più velocemente di quanto in profondità scavare nel mondo arcano della messa a punto e la gestione della memoria Java OS: P

Answer 2

In primo luogo, sei pazzo a eseguire un sistema operativo a 32 bit quando hai così tanta pressione sullo spazio degli indirizzi.Migrazione a una JVM a 64 bit su Linux a 64 bit.Quanto tempo hai già sprecato cercando di diagnosticare questo problema che dovevi sospettare fin dall'inizio sarebbe andato via con lo spazio di indirizzi più ampio di un sistema a 64 bit?

In secondo luogo, è risaputo che tra tutti i fornitori Linux, Red Hat ha il maggior numero di ingegneri del kernel nello staff e apporta alcune modifiche importanti ai kernel nei loro prodotti RHEL.Questi spesso includono patch per carichi di lavoro di grandi dimensioni come il tuo (beh, è ​​un carico di lavoro di grandi dimensioni per un sistema a 32 bit, non è niente di speciale su 64 bit).Quindi c'è qualche possibilità che il motivo in definitiva sia che RHEL abbia altri clienti che fanno le tue stesse cose pazze e tu stai beneficiando del lavoro che hanno svolto per supportare quei clienti.

Infine, però, poiché sospetto che insisterai nel cercare di trovare un modo per farlo su SuSE a 32 bit, farò notare che Linux offre una varietà di compromessi nello spazio degli indirizzi su x86 a 32 bit, ed è possibile (ma non certo) che i tuoi sistemi SuSE abbiano semplicemente selezionato un compromesso diverso.Se riesci a visualizzare la configurazione dei kernel in esecuzione (spesso in /boot/config....), puoi confrontare impostazioni come HIGHMEM.

L'opzione convenzionale fino a qualche anno fa era split 2:2, ovvero lo userspace è limitato a 2GiB di spazio indirizzi, una soluzione facile da programmare e con una discreta efficienza ma in questo scenario ovviamente non puoi avere l'heap richiesto poiché non lascerebbe spazio per il testo del programma, lo stack, ecc.Più recentemente la tendenza è stata quella del 3:1 (simile allo switch Windows /3GB) che espande lo spazio degli indirizzi dello spazio utente al costo di stipare il kernel del sistema operativo stesso in meno spazio, il che potenzialmente causa i suoi stessi problemi.Potrebbe funzionare, ma sarebbe molto angusto, quindi non sarei sorpreso se non funzionasse per il tuo lavoro.Infine, i kernel Linux più recenti offrono anche un'opzione in cui ottieni spazio utente 4GiB a 32 bit, che potrebbe essere sufficiente per far funzionare i tuoi lavori in modo affidabile, con un costo significativo in termini di prestazioni poiché ovviamente lo spazio utente e gli indirizzi del kernel non possono coesistere.

Per provarlo avresti bisogno di un nuovo kernel.Potresti essere in grado di installarne solo uno fornito da SuSE (vedi se ne offrono altri tra cui scegliere, ad es.un'opzione "PAE") o potrebbe essere necessario compilarne uno proprio, nel qual caso probabilmente invalida il contratto di supporto.

Ma in realtà, dovresti semplicemente scegliere l'opzione 1, passare a una JVM a 64 bit e alzare i piedi.