Limiter la consommation totale de mémoire du processus Java (dans Cloud Foundry)

Lié à ces deux questions:

• Comment définir l'utilisation maximale de la mémoire pour JVM?
• Qu'est-ce qui ferait qu'un processus java dépasserait considérablement la limite Xmx ou Xss?

J'exécute une application Java sur Cloud Foundry et je dois m'assurer que la mémoire allouée n'est pas dépassée. Sinon, et c'est le problème actuel, le processus est tué par les mécanismes de surveillance de Cloud Foundry (Linux CGROUP).

Le Buildpack Java automatiquement définit des valeurs saines pour -Xmx et -Xss. En ajustant les arguments et en configurant le nombre (maximum) de threads attendus, je suis à peu près sûr que la mémoire consommée par le processus Java devrait être inférieure à la limite supérieure que j'ai assignée à mon application Cloud Foundry.

Cependant, je rencontre toujours des erreurs de "mémoire insuffisante" de Cloud Foundry (PAS l'erreur Java OOM!): index: 3, reason: CRASHED, exit_description: out of memory, exit_status: 255

J'ai expérimenté le réglage MALLOC_ARENA_MAX. Définir la valeur sur 1 ou 2 conduit à ralentir les démarrages. Avec MALLOC_ARENA_MAX=4 J'ai toujours vu une erreur comme décrit ci-dessus, donc ce n'est pas une solution à mon problème.

Actuellement, je teste avec des paramètres de mémoire très serrés afin que le problème soit plus facile à reproduire. Cependant, même avec cela, je dois attendre environ 20-25 minutes pour l'erreur.

Quels arguments et / ou variables d'environnement dois-je spécifier pour m'assurer que mon processus Java ne dépasse jamais une certaine limite de mémoire? Le plantage avec une erreur Java OOM est acceptable si l'application effectivement besoin de plus de mémoire.

Plus d'informations concernant les 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: Une explication possible est la suivante: http://www.evanjones.ca/java-bytebuffer-leak.html. Comme je vois actuellement le problème OOM lorsque je fais beaucoup de requêtes HTTP/REST sortantes, ces tampons pourraient être à blâmer.