Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Très intéressant ce forum ! 
Je travaille dans le Décisionnel sur un projet très (trop ?!) important où PostgreSQL est utilisé et j'ai un problème lors de l'alimentation de mon entrepôt de données.
Un de mes JOB BO Data Integrator est très très très long lors du 1er passage (une boucle d'une cinquantaine de passages où une même requête UPDATE est exécutée avec des conditions différentes forcément). Il y a jusqu'à 230 000 000 d'Entrées/Sorties lors du 1er passage !!!
Comment puis-je m'assurer que le problème vient bien de là ?
S'il vient bien de là, est-ce que cela explique le fait que le 1er passage est systématiquement beaucoup plus lent que tous les autres qui prennent eux entre 100 fois et 4 fois moins de temps ?!! A partir du 2e passage, chaque passage est d'une régularité déconcertante ! Il n'y a plus que quelques secondes de différence en temps d'exécution, alors que le 1er passage peut durer des dizaines de minutes, voir plus d'1 heure !!!
Désolé, je ne m'y connais que (trop) peu en gestion de BDD. Je sais toutefois qu'une même requête exécutée plusieurs fois est toujours plus rapide, mais me dites pas que ça explique mon problème !? De toute façon, même si cela joue, ce n'est pas la solution à mon problème, car en relançant mon Job plusieurs fois et bien au bout d'un moment, j'arrive à avoir un 1er passage "acceptable" (10 à 15 min).
Enfin, j'ai remarqué que seul le 2e core du 1er CPU est utilisé (entre 85 et 100 %) ?! Notre serveur dispose d'un Dual-CPU Quad Core et de 8 Go de RAM.
Je ne savais pas trop où poster, alors n'hésitez surtout pas à déplacer mon post.
Gôm
PS : Au total, il y a 41 600 000 lignes à traiter, mais je ne sais pas si ça fait avancer le schmilblick !
Dernière modification par gom (13/11/2009 00:05:57)
Hors ligne
Bon juste pour vous dire que je viens de relancer pour la nième fois mon Job et que ça y est tout roule correctement ... bon par contre j'ai plus de cheveux tellement c'est incompréhensible !!!
Au niveau du serveur, j'ai désormais le 1er et le 4e core du 1er CPU qui sont entre 30 et 40 % chacun (des jumeaux) et tous les autres qui frétillent à 5 %. La RAM n'est pas plus sollicitée qu'avant, je suis à 1,8 Go ... sur 8 Go ! Et les Entrées/Sorties sont à 47 000 000 et augmentent très doucement par paquets de 500 à la seconde (grand maximum).
Et avec tout ça ... je traite maintenant 1000 lignes toutes les 2 secondes et ça s'accélèrent !!! Si tout se passe comme la semaine dernière, j'aurai traité mes 41 millions de lignes en moins de 3 heures !!! 
Une idée concernant ce comportement bizarre ?!
Gôm
Dernière modification par gom (13/11/2009 00:25:13)
Hors ligne
Une petite dernière pour la route ... je crois que ça y est la machine a atteint son plein régime.
Je suis à 35 % d'utilisation des CPU et 2,2 Go de RAM. J'ai maintenant systématiquement entre 3 et 6 Cores d'utilisés à plus de 40 %.
Il faut désormais largement moins d'1 seconde pour que 1000 lignes soient traitées !!! Je ne sais pas exactement, mais je dois être à 3 ou 4 milliers par seconde. Enfin bref par rapport au temps final qu'il m'a fallu la semaine dernière ça doit être à peu près la vitesse de croisière ! 
Je suis bon pour aller me coucher ... en rêvant déjà à la semaine prochaine ! Ouiiiiiiin ... 
Gôm
Hors ligne
Bonjour,
L'"augmentation" des performances est probablement du au fait qu'initialement les données ne sont pas en cache, et y arrivent lors du premier chargement. Une fois que c'est fait, les IO sont évidemment moindres.
L'utilisation d'un seul CPU est normale s'il n'y a qu'une session de chargement. S'il y en a plusieurs, ça l'est moins (sauf évidemment si le serveur fait énormément d'IO comme dans le cas de la première passe).
Dernier point : BO Data Integrator ne supporte pas vraiment (à moins qu'ils aient changé récemment) PostgreSQL. Ils utilisent un driver ODBC, avec un comportement générique (même pas de requête préparée si je me souviens bien). Vous obtiendrez probablement de meilleurs performances avec Pentaho Data Integrator ou Talend, si vous en avez la possibilité, et que vous n'avez pas déjà fait tout le travail avec BO
Marc.
Hors ligne
Bonjour,
L'"augmentation" des performances est probablement du au fait qu'initialement les données ne sont pas en cache, et y arrivent lors du premier chargement. Une fois que c'est fait, les IO sont évidemment moindres.
OK, mais comment expliquez-vous le fait que je sois obligé de lancer mon Job n fois avant d'avoir un 1er passage durant quelques minutes ? Les fois précédentes, le 1er passage n'aboutit jamais ! Du moins j'ai laissé tourner mon Job plus d'1 heure et le 1er passage n'était toujours pas fini !?
L'utilisation d'un seul CPU est normale s'il n'y a qu'une session de chargement. S'il y en a plusieurs, ça l'est moins (sauf évidemment si le serveur fait énormément d'IO comme dans le cas de la première passe).
Que voulez-vous dire par "une session de chargement" ?
Dernier point : BO Data Integrator ne supporte pas vraiment (à moins qu'ils aient changé récemment) PostgreSQL. Ils utilisent un driver ODBC, avec un comportement générique (même pas de requête préparée si je me souviens bien). Vous obtiendrez probablement de meilleurs performances avec Pentaho Data Integrator ou Talend, si vous en avez la possibilité, et que vous n'avez pas déjà fait tout le travail avec BO
J'ai bien vu que PostgreSQL n'était pas recommandé par BO, mais comme vous l'avez deviné : tout le travail est déjà fait avec BODI ! Il nous est impossible de changer d'outil d'ETL. Quoi qu'il en soit je ne suis pas sûr que le problème vienne du couple BODI + PostgreSQL, car au bout de plusieurs lancements (sic !) les performances sont tout de même très bonnes, ne pensez-vous pas ?
Gôm
Dernière modification par gom (13/11/2009 12:31:50)
Hors ligne
OK, mais comment expliquez-vous le fait que je sois obligé de lancer mon Job n fois avant d'avoir un 1er passage durant quelques minutes ? Les fois précédentes, le 1er passage n'aboutit jamais ! Du moins j'ai laissé tourner mon Job plus d'1 heure et le 1er passage n'était toujours pas fini !?
Il peut y avoir un rapport énorme entre les performances d'une requête accédant au cache et une devant accéder aux disques (rapport un à mille ou plus). Ne sachant pas exactement ce que vous faites, sans accès au serveur, difficile de vous donner le détail de la cause de votre problème, mais c'est par là qu'il faut chercher je pense.
Que voulez-vous dire par "une session de chargement" ?
Une session à la base, sur laquelle vous envoyez des requêtes.
J'ai bien vu que PostgreSQL n'était pas recommandé par BO, mais comme vous l'avez deviné : tout le travail est déjà fait avec BODI ! Il nous est impossible de changer d'outil d'ETL. Quoi qu'il en soit je ne suis pas sûr que le problème vienne du couple BODI + PostgreSQL, car au bout de plusieurs lancements (sic !) les performances sont tout de même très bonnes, ne pensez-vous pas ?
Pour le chargement de données, PostgreSQL propose un ordre COPY extrêmement rapide, que vous ne pourrez utiliser qu'au prix de contorsions abominables avec BO. Mais si les performances vous satisfont et que tout est déjà en place, ça modifie la donne.
Marc.
Hors ligne
Pages : 1
