Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#126 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 10/03/2010 07:38:39
Bonjour,
Je mets la même valeur qu'en PROD : 4096 (32 Mo si je ne dis pas de bêtises) ou 8192, le maximum que vous me conseillez ? Si 8192, alors autant mettre également cette valeur en PROD, non ?
Petites questions sur ce paramètre :
Est-ce qu'il faut mettre une valeur en fonction de la quantité de RAM ?
Est-ce qu'il existe une quantité de RAM à partir de laquelle, on peut mettre systématiquement 64 Mo ?
Merci en tout cas pour vos précieux conseils et le temps que vous donnez à la communauté.
Gôm
#127 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 19:43:59
Petite précision ... les UPDATE se font désormais en 0 ms selon le Log PostgreSQL ... 900 lignes par seconde selon BODI ! Ouf je suis sauvé ! 
#128 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 19:37:34
Bon, j'ai fait un ANALYSE et le REINDEX est en cours sur cette table. Une fois fini je relance mon Job BODI ... et je rentre chez moi !!!
Dois-je toucher au "shared_buffers" ?
#129 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 19:17:21
C'est un UPDATE simple.
Noooooooooon j'hallucine !!! 
Les Index présents en PROD n'existent pas en DEV !!! 
Du coup je n'ai aucun Index sur la table où ont lieu les UPDATE !!!
#130 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 19:01:48
Je n'ai que des UPDATE et ils durent tous entre 310 et 330 ms, ce qui fait 3 lignes mises à jour chaque seconde ... alors que BODI me dit qu'il faut plus de 3 secondes pour mettre à jour une ligne ! 
Les statistiques remontées par BODI sont peut être fausses (à moins que ce ne soit moi qui comprenne rien au Log de PostgreSQL 
), mais le pire c'est que dans les faits je vois bien que mon traitement met plus de temps que d'habitude ! 
#131 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 18:14:51
Je ne comprends pas d'où vient le problème.
Quoi qu'il en soit si je change le "shared_buffers" comme disait Marc Cousin, que dois-je mettre ? La moitié de la valeur du serveur de PROD, car il y a 2 fois moins de RAM ? A moins que la RAM n'est rien à voir la dedans ...
En sachant que la priorité sur cette machine de DEV, ce sont les INSERT et les UPDATE et non les SELECT. Bon bien sûr il ne faut pas non plus que les problèmes de délai que j'ai avec mes INSERT et UPDATE se reportent sur les SELECT ! 
Gôm
#132 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 16:22:32
Les Commit dans BODI se font par paquet de 1000 lignes et les statistiques indiquaient une moyenne d'une ligne insérée toute les 3,2 secondes.
10.000 lignes /2.847 secondes = 3,5 secondes en moyenne depuis mon lancement à 14h28.
Un problème avec le Commit ?
#133 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 15:38:35
Je crois que j'ai trouvé. Il fallait que je consulte "postgresql-2010-03-09_000000.log" n'est-ce pas ?
Ce fichier contient toutes mes requêtes. Ce sont essentiellement des requêtes UPDATE, elles durent toutes entre 310 et 330 ms. (Cette table contient un peu plus de 500.000 lignes pour 21 colonnes.)
Sinon au lancement de mon Job BODI, j'ai des centaines de lignes comme celle là :
2010-03-09 14:28:57 CET LOG: durée : 0.000 ms
2010-03-09 14:28:57 CET LOG: exécute fetch à partir de <unnamed>/SQL_CUR057CF120: BEGIN;declare "SQL_CUR057CF120" cursor with hold for select col1_xi, col1 from mon_schema.ma_table for read only;fetch 1000 in "SQL_CUR057CF120"
2010-03-09 14:28:57 CET LOG: durée : 0.000 ms
Gôm
#134 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 15:29:55
Merci pour votre aide. J'ai modifié le postgresql.conf et fait un Reload.
Où dois-je aller pour analyser les ordres les plus lents ?
#135 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 15:03:02
La base de PROD fonctionne mais sans plus ... On va passer sous Linux, car c'est apparemment préférable, à voir.
Pour mon problème du jour, c'est la base de DEV qui est concernée.
Au niveau de l'utilisation de notre machine de DEV elle devrait être optimisée également pour les insertions, car le fait d'avoir des temps d'interrogations un peu plus longs qu'en PROD n'est pas gênant (surtout que cette machine a moitié moins de RAM, donc bon ...).
Gôm
#136 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 13:41:52
Voici les écarts que je constate entre ma base de PROD et de DEV :
"checkpoint_completion_target";"0.9"
"checkpoint_segments";"256"
"checkpoint_timeout";"3600"
"default_statistics_target";"100"
"effective_cache_size";"688128";"8kB"
"log_checkpoints";"on"
"log_connections";"on"
"log_disconnections";"on"
"log_line_prefix";"%t [%p]: [%l-1] "
"log_min_duration_statement";"-1"
"log_temp_files";"0";"kB"
"maintenance_work_mem";"524288";"kB"
"max_fsm_pages";"873800"
"max_fsm_relations";"1000"
"max_prepared_transactions";"0"
"shared_buffers";"4096";"8kB"
"temp_tablespaces";""
"vacuum_cost_limit";"200"
"wal_buffers";"128";"8kB"
"work_mem";"307200";"kB"
"checkpoint_completion_target";"0.5"
"checkpoint_segments";"32"
"checkpoint_timeout";"300"
"default_statistics_target";"1000"
"effective_cache_size";"393216";"8kB"
"log_checkpoints";"off"
"log_connections";"off"
"log_disconnections";"off"
"log_line_prefix";"%t "
"log_min_duration_statement";"3000"
"log_temp_files";"-1";"kB"
"maintenance_work_mem";"16384";"kB"
"max_fsm_pages";"2048000"
"max_fsm_relations";"20000"
"max_prepared_transactions";"5"
"shared_buffers";"128000";"8kB"
"temp_tablespaces";"temp"
"vacuum_cost_limit";"2000"
"wal_buffers";"64";"8kB"
"work_mem";"65536";"kB"
Serveur de PROD :
Système d'exploitation : Windows 2003 Server SP2
Processeur : Intel Xeon 2GHz
Mémoire vive : 8 Go
Serveur de DEV :
Système d'exploitation : Windows 2003 Server SP2
Processeur : Intel Xeon 2GHz
Mémoire vive : 3,75 Go
Gôm
#137 Re : Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 13:18:56
"autovacuum";"on"
"autovacuum_analyze_scale_factor";"0.01"
"autovacuum_analyze_threshold";"50"
"autovacuum_freeze_max_age";"200000000"
"autovacuum_max_workers";"3"
"autovacuum_naptime";"60"
"autovacuum_vacuum_cost_delay";"20"
"autovacuum_vacuum_cost_limit";"-1"
"autovacuum_vacuum_scale_factor";"0.2"
"autovacuum_vacuum_threshold";"50"
Donc, le paramétrage est bien tel qu'il m'avait été conseillé de le régler.
Auriez-vous une piste à me donner concernant votre "1." ?
Je ne vois pas pourquoi j'aurais un problème côté applicatif, car mon traitement BODI n'a pas changé et tout fonctionnait très bien la dernière fois que j'ai eu à le lancer.
Gôm
#138 Optimisation » [Version 8.3] INSERT très lent : 1 ligne toutes les 3,2 secondes ! » 09/03/2010 13:05:05
- gom
- Réponses : 41
Bonjour à tous,
Pour vous situer le contexte je ne suis pas DBA, je suis Ingénieur Décisionnel et je travaille notamment avec BO Data Integrator.
Un administrateur PostgreSQL de ma boîte m'avait conseillé il y a quelques mois déjà ceci :
Dans le postgresql.conf de chaque serveur, modifier la ligne #autovacuum_analyze_scale_factor = 0.1 vers autovacuum_analyze_scale_factor = 0.01
J'ai à nouveau des problèmes sur ce serveur et je viens de constater que Postgresql.conf est dans cet état là :
#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------
#autovacuum = on # Enable autovacuum subprocess? 'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least that time.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
#autovacuum_analyze_threshold = 50 # min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
autovacuum_analyze_scale_factor = 0.01 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20 # default vacuum cost delay for
# autovacuum, -1 means use
# vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limitSachant que tout est commenté, sauf la ligne que j'ai ajouté ... elle ne sert à rien, exact ? Si oui, suffit-il que je décommente #autovacuum = on en autovacuum = on ?
Gôm
#139 Re : Optimisation » Requêtes COPY : temps d'exec qui se dégradent » 20/12/2009 20:29:13
Je n'ai pas le choix concernant les index sur ces tables, je suis obligé de les garder, car ils sont indispensables pour d'autres utilisations de ces tables.
Au final le reste des requêtes COPY s'est terminé entre temps, donc je n'ai pas eu à les dropper.
Par contre, je me suis dit qu'il serait bien de lancer ce script avant de relancer un nouveau traitement :
VACUUM ANALYZE VERBOSE
REINDEX DATABASE "MaBaseDeDonnees"Ai-je eu raison ? De toute façon le temps d'exécution final me le dira ! ;-)
Gôm
#140 Re : Optimisation » Requêtes COPY : temps d'exec qui se dégradent » 20/12/2009 10:17:55
Bonjour,
Je pencherais donc pour ta 1ère proposition : la fragmentation des index.
Un palliatif possible pour accélérer l'exécution de la fin de mes requêtes ?
Gôm
#141 Optimisation » Requêtes COPY : temps d'exec qui se dégradent » 20/12/2009 00:33:58
- gom
- Réponses : 5
Bonjour à tous,
J'ai des milliers de requêtes COPY qui sont en cours d'exécution (en ce moment je suis toujours sur la même table). Elles sont lancées à travers Business Objects Data Integrator (mes requêtes COPY sont générées via un Script).
Problème : plus le temps passe et plus le temps d'exécution de chaque requête est long.
N'y aurait-il pas un paramétrage quelconque à modifier ? Paramétrage qui peut être modifié à chaud cela va de soit ! 
Je ne peux bien évidemment pas arrêter mon traitement BODI pour le relancer, car il doit être fini d'ici demain soir.
Gôm
PS : J'entends parfois parler des statistiques sur les tables dont on peut "forcer" le rafraîchissement manuellement, mais je ne sais pas du tout si c'est la solution dans mon cas et je sais encore moins si cette manipulation est réalisable dans mon cas.
#142 Re : Général » BO Data Integrator (1er passage très lent) » 13/11/2009 12:30:48
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
#143 Re : Général » BO Data Integrator (1er passage très lent) » 13/11/2009 00:24:36
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
#144 Re : Général » BO Data Integrator (1er passage très lent) » 13/11/2009 00:14:11
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
#145 Général » BO Data Integrator (1er passage très lent) » 12/11/2009 23:27:49
- gom
- Réponses : 5
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 !