C'est ultra commun de mettre du Xmx à 4G voire plus sur des applications métier, sous peine de refus de démarrer. Sous PHP aussi il y a une limite de mémoire, mais je n'ai jamais vu une appli utiliser autant de ram...
Ç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.
Si tu essaie de faire tourner un log avec logrotate, la JVM va continuer d'écrire dans l'ancien. Il faut alors confier à java la rotation (ce que je trouve pas pratique et pas normal) et ensuite coder des crons dégueux pour faire des find qui compressent et suppriment les anciens fichiers.
Je ne connais pas tous les middlewares du monde, mais je n'en vois que deux qui font ça: Java et MongoDB. Ce dernier ayant au moins une option pour permettre l'utilisation propre de logrotate.
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.
La seule chose que j'ai à dire face à ça: ça ne le fait pas avec les autres langages. Je pense qu'il existe un historique très important de bidules en PHP, et pourtant ça tourne sur des serveurs beaucoup plus petits, ça ne fait pas crasher Apache (ou php-fpm) au moindre pépin, on y colle du logrotate sans problèmes. Ah oui et ça démarre instantanément, pas comme les JVM/JBoss/Wildfly où tu attends parfois 1 minute que ton appli démarre, génial quand tu veux automatiser et que tu dois coder plein de check à chaque étape de ton playbook pour attendre.
[^] # Re: Java > 1.8
Posté par MTux . En réponse au journal Java XII est dehors. Évalué à 0.
C'est ultra commun de mettre du Xmx à 4G voire plus sur des applications métier, sous peine de refus de démarrer. Sous PHP aussi il y a une limite de mémoire, mais je n'ai jamais vu une appli utiliser autant de ram...
Si tu essaie de faire tourner un log avec logrotate, la JVM va continuer d'écrire dans l'ancien. Il faut alors confier à java la rotation (ce que je trouve pas pratique et pas normal) et ensuite coder des crons dégueux pour faire des find qui compressent et suppriment les anciens fichiers.
Je ne connais pas tous les middlewares du monde, mais je n'en vois que deux qui font ça: Java et MongoDB. Ce dernier ayant au moins une option pour permettre l'utilisation propre de logrotate.
La seule chose que j'ai à dire face à ça: ça ne le fait pas avec les autres langages. Je pense qu'il existe un historique très important de bidules en PHP, et pourtant ça tourne sur des serveurs beaucoup plus petits, ça ne fait pas crasher Apache (ou php-fpm) au moindre pépin, on y colle du logrotate sans problèmes. Ah oui et ça démarre instantanément, pas comme les JVM/JBoss/Wildfly où tu attends parfois 1 minute que ton appli démarre, génial quand tu veux automatiser et que tu dois coder plein de check à chaque étape de ton playbook pour attendre.