Suite a mon article sur un peu d’optimisation mémoire en Java, J’ai reçu une question interressante ; ma réponse me semble pouvoir être partagée en complément :

Je me demande si il existe une formule permettant de déterminer quelle taille maximum peut on allouer a l option -Xmx en fonction de la ram, de la taille des fichiers d’échange, …. Si tu as des infos …

En première approche, sans contexte, il ne me semble pas possible de répondre à cette question sous la forme d’une formule toutefois, voici les principaux éléments auxquels je pense :
Je ne pense pas qu’il y ait de formule magique … Java va utiliser la mémoire tant qu’il y en a, y compris s’il n’en a plus besoin en ne passant plus le GC, en tout cas jusqu’a atteindre Xmx – Xms … bref, ca va swapper et ce n’est pas forcement conseillé !
Tout dépend de ce que tu souhaites : éviter un crash de la JVM a tout prix ou preserver les performances. Si l’appli demande plus de mémoire qu’il n’y en a sur le système, je n’ai qu’un conseil : acheter de la RAM.

Pour mon usage personnel, je concidèrerai le paramétrage suivant (à noter qu’il ne s’agit que d’une borne max) :

Xmx – Xms < RAM_totale – RAM_utilisée_hors_JVM – marge (RAM_totale*0.1)

Ce qui peut être proche de :
Xmx < Xms + 0.9*RAM_libre

Ce qui ne répond qu’à moitier à la question puisqu’il reste à déterminer Xms.
Là, tout dépend de l’application ; plus Xms est grand plus tu augmentes Xmx dans mon équation et moins tu risques de saturer la mémoire de la JVM (si c’est le pbm) mais plus tu risques de swapper.
Par ailleurs, attention, si Xmx > RAM_totale tu pénalises les applications autres que Java car Java va utiliser toute la mémoire qu’on lui donne. Dans ce cas tu peux avoir des impacts très forts sur les applications telles que la base de donnée par exemple et pénaliser ton application… d’où bien prendre en compte la RAM_utilisée_hors_JVM et une marge pour ces applications.

Le risque en saturant la RAM est que lors d’un pic d’utilisation tu auras à la fois une JVM surchargée et des applications tierses sans mémoire = écroulement du serveur…(c’est peut-être une banalité ce que je dis là mais rien ne dis qu’il n’y aura pas de la perte de mémoire dans la JVM alors que les autres appli seront dejà HS)
Sauf contexte particulier, la RAM ne coute pas chere et les performances disques sont beaucoup trop médiocres … donc achetez de la RAM !

A l’opposé, si je peux aussi proposer un conseil à ceux qui ne cessent d’acheter de la RAM et voient toujours leur serveur saturés… jouez un peu sur les paramétrages, Java, mais d’autres appli comme Oracle commencent par se mettre la RAM sous le coude ou ne la libère que quand il n’y en a plus… bref, plus on en met et plus ca en consomme. De belles économies en perspective et un meilleurs partages des ressources pour les applications plus eco-citoyennes en quelque sorte.

Par aileurs, cette analyse ne tiens pas vraiment compte de la façon dont le système gère son cache. Hors pour ce qui est de linux, la mise en swap se fait par page mémoire (de l’ordre de 4K) On peut donc imaginer qu’une partie de la mémoire de la JVM, les objets non référencés mais pas encore libérés, va rapidement être mise en swap ; si necessaire et sans domage pour les performances. Alors, pourquoi ne pas libérer la mémoire de la JVM plus tot ? (on en revient à la formule initiale !). Autre impact : le risque de swapper des objets toujours référencés mais peu utilisés ce qui augmentera les temps de réponse sur ces objets. Je reste donc sur ma formule précédente.

Pour finir par un lien avec l’article précédent, Xms ne doit pas être trop grand sans quoi le garbage collector ne passera que rarement et la consommation mémoire “de croisière” pourrait être plus forte que nécessaire ; toutefois c’est à moindre mal.