Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
ça log comme ça veut et ça ne respecte pas les logrotate
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 10.
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
La connaissance libre : https://zestedesavoir.com