Freeze ou crash du serveur applicatif Java, le traqueur peut-il aider ?

[Phil]

Merci à Thomas pour sa question :

"On me demande d'enquêter sur l'indisponibilité des serveurs d'application Java (JBOSS), un problème mémoire a priori. On note qu'à ces heures là il y a un gros trafic réseau depuis le serveur de base de données PostgreSQL. Le traqueur peut-il aider ?"


Réponse :

Oui, bien sûr, si vous le faites tourner en mode batch, par exemple via un service systemd.
Identifier la période ayant provoqué une flambée du trafic réseau de la base vers le(s) serveurs applicatifs, jusqu'à leur plantage éventuel (=> information nécessaire pour analyse DBA avec si possible en plus l'adresse IP du serveur ayant planté)
Sur le serveur bdd, interroger la base traqueur, la table traqueur_sessions_actives en filtrant sur les dtcol pour cibler la période fournie. Repérer notamment le wait_event_type "Client", le wait_event "ClientWrite" et le(s) requête(s) associées, ainsi que le serveur d'application les ayant soumises si l'info a été fournie.
Après obtention des valeurs des éventuels query parameters, vérifier via explain analyze que le(s) requête(s) retournent un volume important de résultats (causes possibles : absence de clause where ou de pagination type order by + (fetch first N rows only ou limit) et probablement pas de positionnement de fetch size côté Java)
De telles requêtes auront toutes les chances d'être les coupables d'un problème mémoire côté serveur applicatif Jboss, Tomcat ou autre, jusqu'à une éventuelle saturation et un arrêt/relance nécessaires.

Si ce volume d'infos à ramener du serveur PostgreSQL vers le serveur d'appli est "légitime" (rare mais ça peut arriver), différences entre les SGBD :
- PostgreSQL ramène tout le jeu de résultats si on ne lui demande pas de faire autre chose, c'est rapide mais consommateur en RAM côté serveur d'appli.
- Oracle fait du streaming au compte-gouttes par défaut, c'est hyper lent mais sûr (enfin pour le serveur d'appli mais pas pour le traitement qui était demandé car, si c'est trop long, il y aura une ORA-1555 donc plantage de la requête...)

Dans tous les cas, si le volume de données à ramener via JDBC est important, il faut souvent paramétrer ce qu'on veut en fonction du besoin car ce qui est fait par défaut n'est pas optimal.