Vous n'êtes pas identifié(e).
Pages : 1
J'ai transmis l'idée au DBA.
Petite précision sur le test en question : les N threads sont vu par le SGBD comme autant de connexion, le SGBD ne me semble pas être dans un cas de parallélisation.
L'applicatif et le SGBD sont sur des machines différentes.
Les logs pour chacun des run font 2Go vu qu'on a activé le full trace du postgres pour pouvoir générer un pgBadger.
Sans le full trace, le log est "normal" d'après mon DBA.
Bonjour,
Je réalise actuellement un POC sur les traitements de masse à l'aide de Spring Batch et lors de la mise en place du multi-threading j'ai remarquer un problème de performance.
Lors de mes test avec 12 threads mes perfs ne sont pas du tout à la hauteur, suites a plusieurs tests je me suis rendu compte que quelque soit le nombre de threads (de 2 à 16) mes perfs batch sont les même. J'ai identifier que le problème provient de mon SGBD postgresql.
L'insertion massive dans mon SGBD par plusieurs thread créer de la concurrence qui augmente très significativement les temps de chaque insert.
Je suis dans un contexte où je ne peux pas utiliser de mécanisme de masse de postgres (COPY) et je ne peux que faire des action unitaire (insert), élément par élément.
Je vous présente mon cas de test que j'ai réalisé pour mettre en évidence mon problème :
Mon processus principal se charge de créer un nombre variable de threads, il se charge de répartir 1 million d'insert parmis les threads et va attendre la fin de chaque thread.
Chaque thread fait le nombre d'insert qu'il à reçu du processus principal, chaque requête insert est la même pour simplifier le test.
Lest résultat de mes test :
Pour 2 threads, les 1 million d'insert se font en 2 minutes
Pour 12 threads, les 1 million d'insert se font en 1 minute
Or, l'ensemble des inserts sont indépendant, mon test se place dans un cas des plus standard : 1 seule table, uniquement un insert, pas d'index, pas de contrainte autre que la clé primaire.
Ma config est des plus puissante pour le SGBD : 6 CPU Intel(R) Xeon(R) CPU E5-2667 0 @ 2.90GHz , le reste étant du même niveau.
J'ai exploré le problème dans tous les sens, j'ai passé plusieurs jours avec mes DataBase Administrator pour essayer de trouver la cause de mon problème mais rien n'y fait, c'est pourquoi je me tourne vers vous.
Les cause classique ont pour la plupart était écarter par les DBA.
le problème est clair : Lors d'un insert unitaire de masse multithreadé, il y a concurrence sans explication ...
Infos diverses :
Chaque thread se connecte une fois et effectue tous les inserts, aucun commit entre les insert.
SGBD en configuration standard, JBoss configuré pour pouvoir gérer les multiples connexion au SGBD.
La requête d'insert est classique "INSERT INTO declarant.entreprise ( dt_creation, dt_maj, version, cd_cat_juridique, cd_motif_siren_annule, cd_naf, dt_cessation_activ_economique, dt_cessation_juridique, dt_creation_entreprise, dt_derniere_maj_emetteur, nb_etablissements_actifs, raison_sociale, sigle, siren ) VALUES ( '2014-04-07 15:54:04.451', '2014-04-07 15:54:04.451', '0', '1000', NULL, '1111Z', '2009-06-01', NULL, '1993-07-28', '2010-09-02', '0', 'RAISON SOCIALE', NULL, '333222111' );"
Au niveau applicatif tout est bien gérer le problème ne peux pas provenir de cette partie.
Analyse pgBadger du test
Total duration Times executed Min duration Max duration Avg duration
Pour 12 Threads
51.333s 254,332 0.000s 0.029s 0.000s
Pour 2 Threads
14.866s 254,332 0.000s 0.011s 0.000s
Je suis de prêt ce post, si vous avez besoin de toute autre information je vous les donnerais.
J'espère que quelqu'un pourra m'aider à trouver la raison ^^
D'avance, merci !
Pages : 1
