2014-12-24 30 views
7

Abbiamo applicato l'applicazione Dockerized di JVM (Java), Java 1.7, e stiamo cercando di decidere come allocare memoria. Abbiamo una singola applicazione in esecuzione nel contenitore finestra mobile. Se al contenitore docker sono allocati 4 GB di RAM, dovremmo assegnare 4 GB (o forse un po 'meno solo per sicurezza) alla JVM?Allocazione memoria JVM nel contenitore Docker (LXC)

Come ho capito, non ci sono altri processi in esecuzione all'interno del contenitore docker oltre a quello che viene chiamato dal punto di ingresso, quindi non dovremmo aver bisogno di preoccuparci dell'utilizzo della memoria non JVM - è vero, o un over semplificazione? Ci sono altre domande che dovremmo porci?

EDIT stiamo usando Mesos/Maratona di distribuire le immagini della finestra mobile - credo che non impostato cgroup limiti di memoria (almeno, dà l'impressione che lo fa), ma potrebbe sicuramente essere sbagliato.

risposta

0

Ai fini della domanda, considerare il contenitore come se fosse un processo in esecuzione sul computer host.

E è un processo in esecuzione sul computer host, anche se con i propri spazi dei nomi per la rete, processo, ecc

non è neppure "allocare" memoria di un contenitore; puoi limite se ti piace tramite cgroups, ma dal momento che la JVM ha il suo limite questo non è necessario.

Infine, in questa situazione si controlla l'utilizzo della memoria virtuale, non la RAM.

+0

Stiamo usando mesos/marathon, quindi credo che limiti la memoria tramite cgroups (anche se potrei sbagliarmi). Per lo meno, abbiamo aspettative di memoria per i container docker, poiché numerosi container verranno schierati fianco a fianco. Tutti aggiungono qualche chiarimento, ma non sono sicuro che questo risponda davvero alla mia domanda - se è limitata, dovremmo limitare la memoria java al limite cgroup? – patwhite

1

Ho lo stesso scenario, e io uso il 90% della memoria riservata alla JVM, e funziona molto bene

+0

Grazie per la risposta! Stiamo facendo qualcosa di simile, e funziona, ma sono davvero curioso degli interni - c'è un sovraccarico dal contenitore stesso che potrebbe influire sull'assegnazione della memoria – patwhite

+1

Lasciare il 90% della memoria riservata a Java è molto rischioso. Il mio suggerimento è di testare la tua applicazione e vedere quanta memoria sta prendendo la JVM. Tieni presente che questa è la memoria riportata dal sistema operativo in quanto può essere significativamente più alta della memoria che hai assegnato all'heap + perm space + threads stack. Solo per darti un'idea, assegnavamo il 75% della memoria del contenitore allo heap. Poi lo abbiamo abbassato al 65% e infine al 50% perché Docker stava uccidendo il contenitore a causa dei limiti di memoria. Con il 50% eravamo bravi. Significa che se in Docker abbiamo assegnato 2G, l'heap JVM era 1G (questo è JDK 8). – dgaviola

+0

Ricorda che i rapporti saranno diversi a seconda dell'app che stai utilizzando. Ad esempio, abbiamo un'applicazione che richiede solo un piccolo heap, circa 64 m, tuttavia, se creiamo un contenitore Docker con 128 m, verrà ucciso a causa dei limiti di memoria. In questo caso abbiamo dovuto assegnare 256 m al contenitore anche quando l'app utilizzava 64 m di heap. Come ho sottolineato nel mio precedente commento, probabilmente quello che devi fare è testare le tue app. – dgaviola

0

Non si può dare lo stesso valore -Xmx come memoria contenitore, perché Java avrà bisogno di un po 'di spazio per la permanente generazione (permgen), cache del codice, eccetera. C'è uno strumento per l'altro ambiente contenitore, Warden. Lo strumento è here: Penso che possa essere usato anche all'interno di Docker. Bisogno di testare

Problemi correlati