Ce topic fait suite à un topic précédemment ouvert et qui n’a pas trouvé solution.
Nous constatons dans Dynatrace que la variable max total est settée à la valeur par défaut 8 et nous essayons sans succès de la passer à 100.
Cela n’a pas fonctionné, on continue de voir la valeur par defaut 8 dans Dynatrace et on continue de souffrir de grandes latences le matin et de crashes.
Nous avons essayé sur un environnement de test, de mettre rajouter la variable dans CATALINA_OPTS et même en dur dans la ligne de commande ci dessous, sans succès:
configuration du pool de connexion => c’est purement de la config Tomcat cf. Apache Tomcat 9 (9.0.69) - The Tomcat JDBC Connection Pool, il n’y a absolument rien de spécifique à Simplicité à ce niveau, on a pas d’expertise pointue sur ce genre de choses
configuration de la JVM = ce genre de chose requiert une expertise Java pointue que nous n’avons pas, là aussi à priori rien de spécifique à Simplicité => faites appel à un expert car notre expérience nous a prouvé que quand on joue sur ces paramètres avancés sans savoir très exactement ce qu’on fait, ça fait plus de mal que de bien
Je viens de communiquer avec notre DEVOPS, les essais que nous avons fait aujourd’hui sur notre preprod et sur notre environnement, c’était avec des “” et cela n’a pas fonctionné non plus.
Nous venons de passer 2 heures avec le devops et quelqu’un de dynatrace à regarder.
Si dans la ligne de commande de start la variable n’existe pas, alors forcément ce seront les valeurs par défaut qui seront prises en compte.
Il n’existe aucune variable d’environnement dans nos images Docker pour jouer sur les caractéristiques de sizing du pool de connexion du datasource. Les variables d’environnement de nos images Docker ne gèrent que les paramètres de connexion.
Si vous voulez vous configurer un datasource “sur mesure” il faut le faire en montant/copiant un context.xml custom ou via des commandes pour altérer celui-ci par défaut dans une image custom.
Ma recommandation est de suivre la doc Tomcat suivante : Apache Tomcat 9 (9.0.83) - The Tomcat JDBC Connection Pool pour configurer le datasource “sur mesure” qui sera le plus adapté à votre cas d’usage particulier. Si j’en crois cette doc le gestionnaire de pool par défaut n’est peut être pas le plus flexible/paramétrable, il faut peut être opter pour l’autre décrit dans cette doc qui saura peut être mieux répondre à vos attentes/contraintes/usages.
Pour ce qui est des arguments JVM, je ne sais pas à quels objectifs précis correspondent les arguments avancés que vous avez ajouté spécifiquement (ex: -XX:+UseContainerSupport -XX:MetaspaceSize=128M -XX:+UseStringDeduplication -XX:MaxRAMPercentage=85.0 -XX:+PrintFlagsFinal -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/heapdump-pvc/ -Xlog:gc:file=/mnt/heapdump-pvc/gc-%t.log:utctime,pid,level,tags:filecount=10,filesize=100M etc.) mais, à nouveau, mon humble expérience dans ce domaine c’est que plus on joue sur ces paramètres avancés plus ça induit potentiellement des effets inattendues voire parfois des crash JVM et autres choses non souhaitables qui ne se produisent pas avec les arguments par défaut de la JVM.
Personnellement, je n’ajoute jamais ce genre de choses car je ne maitrise pas leurs effets, je considère que la config par défaut de la JVM fait forcément mieux le job que tout ce que je pourrai “bricoler” à ce niveau.
Bref, si ces arguments ont été ajoutés par un super expert Java de haut vol qui sait parfaitement ce qu’il fait je ne le discuterai pas car je n’ai pas les compétences pour, mais si c’est en mode expérimental/empirique que vous avez ajouté ça je vous conseille de revenir à des choses plus basiques et de voir comment ça se comporte sans.
Bonjour David,
Je ne pense pas que setter le pool de connexion selon les préconisations de l’éditeur puisse être considéré comme un volonté projet de configurer un data source “sur mesure”.
Modifier le context.xml en ajoutant les variables considérées, puis retstarter le Tomcat, c’est ce que nous avons fait.
Mais peut-être avez vous raison et nous devons peut-être considérer d’utiliser un autre gestionnaire que celui par défaut.
Nous allons continuer à expérimenter des choses sur nos instances de test.
Merci encore de vos retours.
Oui, visiblement le gestionnaire de pool de connexion alternatif Tomcat est plus adapté dans certaines situations et gère visiblement plus de paramètres pour un tuning “fin”.
Nous n’avons malheureusement pas de retour d’expérience sur l’utilisation de ce gestionnaire de pool mais, à nouveau, il n’y a rien de spécifique à Simplicité au niveau de la configuration des datasources Tomcat.
Au niveau du code de Simplicité on invoque ces datasources de manière générique/standard, i.e. indépendamment de la manière dont ils sont configurés au niveau Tomcat, c’est bien un des intérets de se baser sur un serveur Tomcat que de ne pas avoir à gérer les connexions à la base de données au niveau applicatif.
La config du datasource volontairement minimal que l’on met par défaut dans nos images Docker répond à 99% des cas d’utilisation, pour les besoins plus spécifiques il faut adapter sa configuration au contexte, rien d’anormal à cela mais c’est au delà de notre domaine d’expertise éditeur.
PS: il faudrait aussi que vous vous assurer que les arguments JVM custom que vous utilisez n’ont pas d’effet néfaste sur Tomcat et, plus particulièrement, sur sa gestion des datasources. Nous livrons nos images Docker sans aucun argument de ce genre justement pour éviter tout effet de bord non maitrisable. Là aussi le tuning pontu de la JVM au delà de notre domaine d’expertise éditeur.
