Limitare il consumo totale di memoria del processo Java (in Cloud Foundry)
In relazione a queste due domande:
- Come impostare l'utilizzo massimo della memoria per JVM?
- Cosa causerebbe un processo Java per superare notevolmente il limite Xmx o Xss?
Eseguo un'applicazione Java su Cloud Foundry e devo assicurarmi che la memoria allocata non venga superata. Altrimenti, e questo è il problema attuale, il processo viene ucciso dai meccanismi di monitoraggio di Cloud Foundry (Linux CGROUP).
Il Buildpack Java automaticamente imposta valori sani per -Xmx e -Xss. Sintonizzando gli argomenti e configurando il numero (massimo) di thread attesi, sono abbastanza sicuro che la memoria consumata dal processo Java dovrebbe essere inferiore al limite superiore che ho assegnato alla mia applicazione Cloud Foundry.
Tuttavia, continuo a riscontrare errori di "memoria esaurita" di Cloud Foundry (NON l'errore Java OOM!):
index: 3, reason: CRASHED, exit_description: out of memory, exit_status: 255
Ho sperimentato l'impostazione MALLOC_ARENA_MAX. Impostare il valore su 1 o 2 porta a rallentare le startup. Con MALLOC_ARENA_MAX=4 Ho ancora visto un errore come descritto sopra, quindi questa non è una soluzione per il mio problema.
Attualmente provo con impostazioni di memoria molto strette in modo che il problema sia più facile da riprodurre. Tuttavia, anche con questo, devo aspettare circa 20-25 minuti perché si verifichi l'errore.
Quali argomenti e/o variabili di ambiente devo specificare per garantire che il mio processo Java non superi mai un determinato limite di memoria? L'arresto anomalo con un errore Java OOM è accettabile se l'applicazione in realtà ha bisogno di più memoria.
Ulteriori informazioni su MALLOC_ARENA_MAX:
- https://github.com/cloudfoundry/java-buildpack/pull/160
- https://www.infobright.com/index.php/malloc_arena_max/#.VmgdprgrJaQ
- https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en
EDIT: una possibile spiegazione è questa: http://www.evanjones.ca/java-bytebuffer-leak.html . Poiché attualmente vedo il problema OOM quando si eseguono molte richieste HTTP/REST in uscita, questi buffer potrebbero essere da biasimare.
1 answers
Sfortunatamente, non c'è modo di imporre definitivamente un limite di memoria sulla JVM. La maggior parte delle regioni di memoria sono configurabili (-Xmx, -Xss, -XX:MaxPermSize, -XX: MaxMetaspaceSize, ecc.) ma quello che non puoi controllare è la memoria nativa. La memoria nativa contiene tutta una serie di cose dai file mappati in memoria alle librerie native al codice JNI. Il meglio che puoi fare è profilare la tua applicazione, scoprire dove si sta verificando la crescita della memoria e risolvere la crescita o darti abbastanza spazio per respirare sopravvivere.
Certamente insoddisfacente, ma alla fine non molto diverso da altri linguaggi e runtime che hanno no controllo sulla loro impronta di memoria.