Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Migration » Informix vers PG » 27/02/2015 09:59:50
Bonjour,
merci à tous les deux!
Jeanmarcb est ce que vous avez un lien pour ces tutos?
#27 Migration » Informix vers PG » 23/02/2015 17:41:09
- Postgres.0
- Réponses : 3
Bonjour,
Je cherche des outils ou des indications pour faire une migration de Informix vers postgres
Merci
#28 Re : Migration » Migration informix Postgres - Volumétrie des bases » 23/02/2015 13:36:14
Bonjour,
pourriez vous nous dire comment faire la migration de Informix vers postgres.
Merci
#29 Re : Optimisation » Optimisation d'une requête PG 9.2 » 16/12/2014 18:08:59
Merci beaucoup!
Je reviens sur cette histoire d'index:
est-ce-qu'il n'est pas mieux que je remplace les index de la table point par:
"point_pkey" PRIMARY KEY, btree (date_, id_equipement, id_type_donnee, id_site)
"idx_optim_elec_conso" UNIQUE, btree (id_equipement, date_)
idx_site" btree (id_site)
J'ai l'impression qu'il y a de la redondance dans les index de cette table.
On essaye aussi de gagner de l'espace en supprimant quelques index.
#30 Re : Optimisation » Optimisation d'une requête PG 9.2 » 16/12/2014 10:55:06
Bonjour Sébastien,
pour cette requête, je n'ai qu'une seule connexion.
J'ai agrandi le work_mem à 3 GB car le fichier temporaire peut dépasser 1GB.
Il n'ya pas d'index sur la colonne indicateur.
Les statistiques sont calculées une fois tous les soirs.
Normalement, postgres est capable de savoir si le plan d’exécution est meilleurs avec la jointure avant le predicat.
Je vais tester cela.
PS:
ne pensez vous pas qu'il y a des index en trop sur la table point?
#31 Optimisation » Optimisation d'une requête PG 9.2 » 15/12/2014 20:08:46
- Postgres.0
- Réponses : 6
Bonjour,
je sollicite votre aide pour optimiser cette requête.
J'ai augmenter le work_mem jusqu'à 3 GB et rien n'a changé.
Le shared_buffers est de 4GB et la RAM est de 16 GB.
La table point a 172721268 enregistrements alors que la table equipement a 4971
id est la clef primaire de la table equipement (la colonne zone_usage n'est pas indexée)
Pour la table point, j'ai la liste d'index suivante:
"point_pkey" PRIMARY KEY, btree (date_, id_equipement, id_type_donnee, id_site)
"idx_optim_elec_conso" UNIQUE, btree (id_equipement, date_)
"idx_conso_site" btree (id_site, date_)
"point_cons_fk_equipement" btree (id_equipement)
EXPLAIN ANALYZE SELECT pec.id_site,
eq.zone_usage,
date_trunc('hour'::text, pec.date_ - '00:05:00'::interval) AS date_,
sum(pec.valeur_conso_hc) AS somme_valeur_conso_hc,
sum(pec.valeur_conso_hp_base) AS somme_valeur_conso_hp_base,
sum(pec.indicateur_index_courant) AS indicateur_index_courant,
count(*) AS cnt,
count(pec.valeur_conso_hc) AS cnt_valeur_conso_hc,
count(pec.valeur_conso_hp_base) AS cnt_valeur_conso_hp_base,
count(pec.indicateur_index_courant) AS cnt_indicateur_index_courant,
count(pec.id_site) AS cnt_id_site,
count(pec.date_consolidation) AS cnt_date_,
count(eq.zone_usage) AS cnt_zone_usage
FROM point pec,
equipement eq
WHERE pec.indicateur >= 0 AND eq.id = pec.id_equipement
GROUP BY pec.id_site, eq.zone_usage, date_trunc('hour'::text, pec.date_ - '00:05:00'::interval);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=42164787.08..49865424.13 rows=118471340 width=36) (actual time=1018575.485..1376888.584 rows=12211544 loops=1)
-> Sort (cost=42164787.08..42587899.01 rows=169244770 width=36) (actual time=1018575.429..1182980.697 rows=160104057 loops=1)
Sort Key: pec.id_site, eq.zone_usage, (date_trunc('hour'::text, (pec.date_ - '00:05:00'::interval)))
Sort Method: external merge Disk: 10324472kB
-> Hash Join (cost=23688.77..9778075.78 rows=169244770 width=36) (actual time=8715.238..436374.256 rows=160104057 loops=1)
Hash Cond: (pec.id_equipement = eq.id)
-> Seq Scan on point pec (cost=0.00..5311711.80 rows=169244770 width=42) (actual time=0.024..311807.117 rows=160104057 loops=1)
Filter: (indicateur >= 0)
Rows Removed by Filter: 2985255
-> Hash (cost=17716.12..17716.12 rows=477812 width=10) (actual time=8714.963..8714.963 rows=9323 loops=1)
Buckets: 65536 Batches: 1 Memory Usage: 421kB
-> Seq Scan on equipement eq (cost=0.00..17716.12 rows=477812 width=10) (actual time=0.020..8711.093 rows=9323 loops=1)
Total runtime: 1379592.078 ms
schemaname | public
tablename | point
attname | indicateur
inherited | f
null_frac | 0
avg_width | 2
n_distinct | 5
most_common_vals | {0,1,2,-1,-2}
most_common_freqs | {0.708667,0.2434,0.0293333,0.0184333,0.000166667}
histogram_bounds |
correlation | 0.681645
most_common_elems |
most_common_elem_freqs |
elem_count_histogram |
schemaname | public
tablename | point
attname | id_equipement
inherited | f
null_frac | 0
avg_width | 8
n_distinct | 2432
most_common_vals | {1387,4042,30,610,81,95,611,256,506,595,1288,1398,74,1182,231,471,591,32,72,505,590,2546,162,181,4041,73,232,654,788,31,100,129,1270,98,102,250,2505,35,101,130,1388,2115,77,245,255,1432,4019,273,1127,1273,1282,1390,1421,1592,1593,1674,2085,4017,93,126,209,246,249,272,285,365,395,1221,2106,2547,94,182,366,411,476,515,1582,2444,575,576,125,396,596,1220,1553,1583,105,208,284,346,520,1181,2551,2586,620,1435,2587,4090,265,410}
most_common_freqs | {0.00243333,0.0024,0.0023,0.0023,0.00226667,0.00226667,0.00216667,0.00213333,0.00213333,0.0021,0.00206667,0.00206667,0.00203333,0.00203333,0.002,0.002,0.002,0.00196667,0.00196667,0.00196667,0.00196667,0.00196667,0.0019,0.0019,0.0019,0.00186667,0.00186667,0.00186667,0.00186667,0.00183333,0.00183333,0.00183333,0.00183333,0.0018,0.0018,0.0018,0.0018,0.00176667,0.00176667,0.00176667,0.00176667,0.00176667,0.00173333,0.00173333,0.00173333,0.00173333,0.00173333,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.0017,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00166667,0.00163333,0.00163333,0.00163333,0.00163333,0.00163333,0.00163333,0.00163333,0.00163333,0.0016,0.0016,0.00156667,0.00156667,0.00156667,0.00156667,0.00156667,0.00156667,0.00153333,0.00153333,0.00153333,0.00153333,0.00153333,0.00153333,0.00153333,0.00153333,0.0015,0.0015,0.0015,0.0015,0.00146667,0.00146667}
histogram_bounds | {9,49,116,203,335,375,470,653,1094,1265,1324,1433,1530,1608,1757,2103,2483,2613,2829,4001,4028,4050,4068,4106,4150,4209,4253,4312,4353,4382,4443,4514,4609,4679,4694,4714,4736,4750,4763,4776,4795,4822,4858,4887,4919,4971,5006,5035,5068,5106,5152,5224,5287,5340,5394,5469,5499,5530,5561,5597,5664,5706,5760,5816,5863,5937,6006,6039,6111,7787,9221,13689,16377,18771,21716,25325,30038,31777,36059,36657,42331,46399,53610,56959,60507,63859,72433,78750,82894,86880,91328,108088,110853,112707,120967,122677,122802,122912,123045,123229,132770}
correlation | 0.624238
most_common_elems |
most_common_elem_freqs |
elem_count_histogram |Pour la table point la colonne date_ a 139670 valeurs distinctes e la colonne correlation est de 0.953307
PS:
je ne suis pas celui qui a créé ces index 
Merci bcp
#32 Re : Général » pg_stat_bgwriter PG 9.2 » 09/12/2014 15:22:19
Gleu,
si mes souvenirs sont bons, j'ai appris cette formule sur ce forum y a quelques années.
Je vais l'oublier
Merci à tous les deux.
#33 Re : Général » pg_stat_bgwriter PG 9.2 » 08/12/2014 15:55:13
Merci Sébastien,
donc la fameuse formule max_connection*work_mem + autovacuum_workers*maintenance_work_mem + shared_buffers < RAM est super approximative
En réalité elle dépend de ce que fait chaque connexion.
#34 Re : Général » pg_stat_bgwriter PG 9.2 » 08/12/2014 15:38:14
Merci beaucoup,
j'en profite pour vous poser une question sur le work_mem:
est-ce-que chaque connexion à la base postgres utilise une quantité de mémoire:
égale exactement à work_mem,
ou bien inférieure ou égale au work_mem,
ou simplement seule les connexions qui font des tris utilise une quantité de mémoire inférieure ou égale à work_mem?
Merci beaucoup
#35 Re : Général » pg_stat_bgwriter PG 9.2 » 08/12/2014 12:34:17
les fichiers sont écrits en séquentiel.
On a 4 programmes qui tournent en simultané (les 3 autres ne font pas de COPY)
#36 Re : Général » pg_stat_bgwriter PG 9.2 » 08/12/2014 11:35:44
Bonjour,
je rebondis sur ce fil pour comprendre un peu plus la bue bgwriter .
En consultant cette vue, j'ai le résultat suivant:
SELECT * FROM pg_stat_bgwriter ;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 631
checkpoints_req | 26
checkpoint_write_time | 196711343
checkpoint_sync_time | 915740
buffers_checkpoint | 4718863
buffers_clean | 4266827
maxwritten_clean | 19963
buffers_backend | 7151369
buffers_backend_fsync | 0
buffers_alloc | 90714584
stats_reset | 2014-12-01 18:01:35.054356+01checkpoint_timout = 15 mn
checkpoint_segment = 100
checkpoint_completion_target =0.9
Les paramètres du bgwriter sont ceux par défaut.
Mon programme utilise l'outil COPY.
On fait COPY de fichier vers une table unlogged ( de centaines de fichiers)
Ma question est comment faire pour baisser la valeur de buffers_backend?
Merci d'avance
#37 Re : Général » pg_stat_bgwriter PG 9.2 » 10/11/2014 14:51:03
Merci,
quand j'analyse ces résultats, j'ai l'impression que le bgwriter est désactivé ( à part le checkpointer).
Avez vous une piste pour avoir une requête qui pourrait donner des résultats en terme de pourcentage comme ceci
background writer relative stats
checkpoints_timed | minutes_between_checkpoint | buffers_checkpoint | buffers_clean | buffers_backend | total_writes | avg_checkpoint_write
-------------------+----------------------------+--------------------+---------------+-----------------+--------------+----------------------
100% | 10 | 46% | 0% | 53% | 0.933 MB/s | 259.000 MB
(1 row#38 Général » pg_stat_bgwriter PG 9.2 » 07/11/2014 13:44:33
- Postgres.0
- Réponses : 13
Bonjour,
en analysant les valeurs de la vue pg_stat_bgwriter, j'ai le buffer_clean qui reste bloqué à 23, alors que buffer_backend grossit.
Est-ce-que ça dégrade les performances?
Si oui qu'est-ce-que je pourrais faire?
à quoi sert le paramètre checkpoints_timed et est-ce normal que checkpoints_req reste à 1?
Je trouve également bizarre que le maxwritten_clean soit à 0.
checkpoint_segments = 80
checkpoint-timeout = 5mn
shared_buffers = 4GB
checkpoint_completion_target = 0.9
RAM =16GB
# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 0 ]---------+------------------------------
checkpoints_timed | 237
checkpoints_req | 1
checkpoint_write_time | 39773784
checkpoint_sync_time | 7129
buffers_checkpoint | 823028
buffers_clean | 23
maxwritten_clean | 0
buffers_backend | 105569
buffers_backend_fsync | 0
buffers_alloc | 456065
stats_reset | 2014-11-06 14:29:56.565245+01
# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 252
checkpoints_req | 1
checkpoint_write_time | 43817023
checkpoint_sync_time | 7403
buffers_checkpoint | 871846
buffers_clean | 23
maxwritten_clean | 0
buffers_backend | 111356
buffers_backend_fsync | 0
buffers_alloc | 475245
stats_reset | 2014-11-06 14:29:56.565245+01
# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 2 ]---------+------------------------------
checkpoints_timed | 259
checkpoints_req | 1
checkpoint_write_time | 45702794
checkpoint_sync_time | 7550
buffers_checkpoint | 899327
buffers_clean | 23
maxwritten_clean | 0
buffers_backend | 114818
buffers_backend_fsync | 0
buffers_alloc | 478767
stats_reset | 2014-11-06 14:29:56.565245+01La vue pg_stat_database:
SELECT sum(blks_read), sum(blks_hit) FROM pg_stat_database;
sum | sum
7196472| 107088786978
sum | sum
---------+--------------
7196582 | 107157863933
sum | sum
---------+--------------
7219176 | 113175378133
select name,setting from pg_settings where name like 'bgw%';
-[ RECORD 1 ]--------------------
name | bgwriter_delay
setting | 200
-[ RECORD 2 ]--------------------
name | bgwriter_lru_maxpages
setting | 100
-[ RECORD 3 ]--------------------
name | bgwriter_lru_multiplier
setting | 2Merci d'avance
#39 Re : Général » IO congestion PG 9.3 » 03/11/2014 17:32:23
Merci beaucoup
#40 Re : Général » IO congestion PG 9.3 » 03/11/2014 11:22:11
Oui les disques durs sont virtualisés et en RAID5.
#41 Général » IO congestion PG 9.3 » 31/10/2014 12:22:04
- Postgres.0
- Réponses : 5
Bonjour,
j'ai une base qui fait 140GB, elle prend 3GB par semaine.
Aujourd'hui, les calculs restent bloqués à cause d'un ExclusiveLock sur des inserts.
Apparemment, avant de faire un insert le processus essaye de rajouter 8KB à la table et il a besoin d'un ExclusiveLock on extension sur la table.
Sauf que cet table est verouillé par un autre processus.
Et j'ai ce message dans la log:
07:12:01 CET LOG: process 16540 still waiting for ExclusiveLock on extension of relation 18304 of database 18294 after 1000.071 ms
Oct 31 07:12:01 serv10 postgres[16540]: [3-2] 2014-10-31 07:12:01 CET STATEMENT: Insert into Table_Journal(ID, DATE_I, DOMAINE_TRAIT, CODE_TRAIT, SMS_LIBRE, STATUT_TRAIT, R_ECHEC, ID_UTIL, ID_S) values (nextval('se_jb'), localtimestamp, 'BATCH', 'INSERT', 'Fichier : C_480_20141031T060000500.xml - 4 él(s) insérée(s) | 0 rel v non insérée(s) ', 0, null, null, 450)
Oct 31 07:12:03 serv10 postgres[27141]: [674-1] 2014-10-31 07:12:03 CET WARNING: pgstat wait timeoutQuelqu'un aurait-il une idée sur des paramètres à tuner ou quelque chose dans le genre.
On est sur des VM et l'admin dit qu'il faut rajouter des disques car y aura bientôt plus d'espace.
Merci d'avance
#42 Re : Général » unexpected EOF on client connection with an open transaction » 17/10/2014 15:21:34
Mon problème vient d'un souci au niveau réseau. Il y a eu une attaque qui a provoqué plusieurs coupures réseaux.
#43 Re : Général » unexpected EOF on client connection with an open transaction » 17/10/2014 15:19:24
Merci beaucoup, c'est clair!
#44 Re : Général » unexpected EOF on client connection with an open transaction » 17/10/2014 14:40:36
Quand il y a une coupure réseau, la connexion n'est pas rendu proprement au sreveur?
#45 Général » unexpected EOF on client connection with an open transaction » 17/10/2014 10:20:53
- Postgres.0
- Réponses : 5
Bonjour,
j'ai un traitement batch prévu tous les soirs à 2h, depuis quelques mois.
Sauf qu'hier soir, ce traitement n'est pas passé.
Quand j'ai analysé la log postgres, je suis tombé sur deux erreurs:
unexpected EOF on client connection with an open transaction
en suite,
FATAL remaining connection slots are reserved for non-replication superuser connections
Juste avant 2h, j'ai plusieurs insertions en base qui echouent.
Est ce qu'on peut dire que chaque insert échoué correspond à une transaction mal fermée?
Un autre script, tjs peu avant 2h, lance plusieurs requêtes concurrentes ( le tout entre un BEGIN et un END).
Est-ce-que je peux dire que chaque requête monopolise une connexion?
Pour information,
je suis sur une 9.3
le max_connections est 200
Comment pourrai-je savoir la raison de mon problème?
Merci d'avance!
Cordialement
#46 Re : Migration » Migration MySQL To Postgres » 07/10/2014 11:19:39
Merci à tous les deux,
j'ai commencé à explorer la piste pgLoader, cependant, je n'ai pas l'impression qu'il puisse migrer les procédures les fonctions et les triggers.
qu'en pensez vous?
#47 Migration » Migration MySQL To Postgres » 03/10/2014 14:47:20
- Postgres.0
- Réponses : 5
Bonjour,
j'ai besoin de vos conseils pour le choix d'un outil qui me permettra de migrer une base mysql vers postgres.
Merci
#48 Re : Général » Connexion à PG 9.3 super lente » 30/09/2014 10:55:57
Merci beaucoup, je vais creuser cette piste.
#49 Re : Général » Connexion à PG 9.3 super lente » 29/09/2014 17:10:37
Le seul message que j'ai dans la log est:
paquet de démarrage incomplet
#50 Re : Général » Connexion à PG 9.3 super lente » 29/09/2014 17:01:40
Le problème peut arriver après redémarrage de tomcat avec un seul utilisateur qui essaye de se connecter.