Discussion :

[Le Marlou]

Bonjour,

J'ai un web service Java qui offrent diverses méthodes de remplissage d'une base données. Chaque requête d'insertion en base est très simple (un insert d'une ligne dans une table ou 2).
Je réalise des tests de perf avec JMeter, dans lesquels je fais 100.000 appels web services en 8 heures. Ces tests se passent très bien sur une base Oracle 11.2.0.2.0 mono instance.
Par contre, lorsque je fais les mêmes tests sur une base Oracle RAC 2 noeuds (même version 11.2.0.2.0), sur les 100.000 appels, j'en ai toujours une dizaine dont le temps de réponse est de plus de 15 minutes.
Quand je dis 15 minutes, c'est vraiment 15 minutes et quelques secondes (comme si il y avait un blocage pendant 900 secondes).

La connexion vers la base est faite en JDBC THIN, et avec un pool de connexions géré avec Apache DBCP.
Suite à des recherches sur le net, une première idée a été de passer en JDBC OCI.
Mais cela n'a pas résolu le problème, il y a toujours un petit nombre de requêtes qui prennent 15 minutes et qq secondes.

Auriez-vous une idée de l'origine du problème ?

Merci d'avance
Le marlou

[tchize_]

a vue de pifomètre, un problème dans la config de oracle. Il vaudrait mieux investiguer ça avec ton DBA. Si t'as du oracle avec RAC a disposition, tu dois avoir quelques DBA sous le coude capable de te sortir les sessions bloquées et de te dire sur quoi elles sont verrouillées. Je gage qu'elles attendent un verrou sur la table, qu'elles peuvent pas l'avoir (concurrence) et que, pour des raisons obscures, elle fait passer les autres transactions en priorité (option 1)

autre possibilité (option 2), si tu utilise un pool de connexion, la solution de pooling choisie gère mal dans certains cas les demande et relègue certains thread pendant 15 minutes en fin de queue d'attente.

solution barbare:
une watchdog qui surveille coté serveur tous tes thread http, quand il en trouve un qui "tourne" depuis plus de 5 minutes, il affiche le nom du thread dans le fichier de log avec un message d'erreur et envoie au process java le signal 3 (lancer un thread dump). Tu aura alors le nom du thread bloqué et dans le dump tu pourra retrouver sa stack trace. Bien faire attention à ne le lancer le kill qu'une fois par thread découvert. Sinon tu va te retrouver avec un log de 500G demain matin

[Le Marlou]

merci pour ta réponse.
Il y a bien un DBA, mais il est en congés 4 semaines, et on doit livrer avant fin Aout... (oui, je sais, c'est naze... )
Je vais regarder du coté du pool de connexion pour voir s'il n'y a pas des options à modifier (j'ai quasiment tout laissé par défaut, à part le nb de connexions)

[tchize_]

Et si il y a un problème avec le DB vous vous tournez les pouces 4 semaines?

[Le Marlou]

Et si il y a un problème avec le DB vous vous tournez les pouces 4 semaines?

en effet, d'où mon désarroi...
Il y a qq personnes qui connaissent à peu pres oracle mais pas du tout le RAC...

[tchize_]

Pas besoin de connaitre oracle pour savoir inspeter v$session ou les vues de lock et de transaction d'oracle. Perso j'en suis incapable mais un DBA (ou un développeur motivé avec les bons droits) doit pouvoir trouver.

Sinon tu peux comme j'ai expliqué essayer de tracer les blocage de ton coté pour commencer