2012-03-12 5 views
6

Ho un nuovo VPS per eseguire alcuni programmi Java che io e alcuni amici abbiamo fatto. Comincio il processo con una linea come questa:Java sta allocando 2gb di memoria in più

java -Xmx512M -jar program.jar 

Sul nostro vecchio VPS, è possibile utilizzare il comando 'top' per vedere come veniva usata molta memoria virtuale e residente. Userebbe come 600-700 MB di memoria virtuale. Ora sul nostro nuovo VPS, con lo stesso comando, la memoria virtuale sembra essere sempre un extra ~ 2gb rispetto al valore -Xmx. Quindi, invece della memoria virtuale intorno ai 600-700mb, è invece 2700-3000mb.

Il vecchio VPS esegue CentOS 5.7 e il nuovo esegue CentOS 6.2. Entrambi eseguono JRE 1.7u3 a 64 bit.

Perché è questo e come posso risolvere il problema?

edit: top

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
27645 pyro 20 0 3003m 270m 10m S 5.0 1.7 1:19.18 java -Xmx512M -jar cserver.jar 

un'altra edit: Non metto in discussione il motivo per cui la memoria virtuale utilizza più memoria di quanto specificato nella riga di comando java. Sto mettendo in discussione il motivo per cui sta usando molto di più rispetto al passato.

+1

Controlla che il tuo processo java utilizzi definitivamente il parametro Xmx512m usando 'ps -ef', e se davvero lo è, aggiorna la tua domanda con l'output di top. – Rich

+0

Se la dimensione del residente è 270 MB e non vi sono problemi di paginazione, c'è un problema? –

+0

Se il programma non è cambiato dal vecchio VPS, e con il vecchio VPS, la memoria virtuale userebbe solo ~ 600-700mb, quindi sì qualcosa non sembra giusto. Sia il vecchio che il nuovo VPS eseguono lo stesso sistema operativo e la stessa versione di Java. –

risposta

4

L'heap non è l'unica cosa che consuma memoria virtuale. La memoria virtuale è la quantità di spazio degli indirizzi dell'applicazione piuttosto che la quantità di memoria che utilizza (il residente è un indicatore migliore)

La memoria virtuale include tutto lo spazio dello stack di thread, la memoria diretta e i file mappati in memoria.

La prima cosa da controllare è il numero di thread utilizzati dall'applicazione, più thread, più memoria virtuale.

+0

Sono consapevole della cosa della memoria virtuale. Sono solo curioso di sapere perché stia allocando così tanta memoria su questo nuovo VPS. Entrambi i VPS utilizzano la stessa versione di Java (1.7u3) e lo stesso OS (CentOS 6.2). Oltre a ciò, il programma non è stato modificato dal momento dello switch VPS. –

+0

Se si esegue 'pmap -x {pid}'. Spesso quando la gente dice che nulla è cambiato, significa che non sanno nulla di ciò che è cambiato, ma chiaramente qualcosa ha. ;) –

+0

Grazie per il comando pmap. Apparentemente sono stato disinformato, uno dei miei amici mi ha detto che il nostro vecchio VPS era in realtà CentOS 5.7 e non 6.2. Ho scoperto che il 'problema' (che non è affatto un problema) è con la mappatura dell'heap anonimo di glibc 2.11. –

1

L'utilizzo della memoria virtuale indica la quantità di spazio degli indirizzi utilizzata e non si traduce necessariamente direttamente nell'utilizzo della RAM. I file stack, mappati (compresi i file binari e le librerie), ecc., Contribuiscono tutti alla memoria virtuale ma non sempre alla RAM effettivamente utilizzata. Si noti che l'utilizzo della memoria RES (resident in RAM) è solo 270 MB piuttosto carino. Su una macchina a 32 bit, è possibile che si verifichino limiti di spazio degli indirizzi, quindi la memoria virtuale è una risorsa scarsa se ci si avvicina al segno di 2 GB (il valore può anche essere 1 GB o 3 GB a seconda del sistema operativo). Su un sistema a 64 bit, la memoria virtuale (spazio degli indirizzi) è quasi illimitata, quindi di per sé un valore elevato non deve essere considerato come un rischio. Naturalmente, se è anche legato all'effettivo utilizzo della RAM o di molti file mappati che non riesci a scoprire perché vengono utilizzati, vale la pena esaminare.

Ovviamente, JVM ha anche un sovraccarico effettivo (nella memoria allocata fisicamente), correlato al mantenimento della garbage collector, al lavoro del compilatore, al codice nativo ecc. E questo si rifletterà anche nell'utilizzo della memoria virtuale. Ma dal momento che le posizioni RES e SHR non sono molto alte, direi che non c'è motivo di farsi prendere dal panico, specialmente se si è 64-bit.