Vous n'êtes pas identifié(e).
Pages : 1
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
Dernière modification par Postgres.0 (07/11/2014 14:24:17)
Hors ligne
Est-ce-que ça dégrade les performances?
Tout seul, non.
Si oui qu'est-ce-que je pourrais faire?
Il n'a pas besoin d'augmenter.
à quoi sert le paramètre checkpoints_timed et est-ce normal que checkpoints_req reste à 1?
La colonne checkpoints_timed indique le nombre de checkpoints exécutés suite au dépassement du délai configuré avec le paramètre checkpoint_timeout.
Quant à la colonne checkpoints_req restant à 1, ce n'est pas anormal.
Guillaume.
Hors ligne
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 rowHors ligne
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
Dernière modification par Postgres.0 (08/12/2014 11:36:16)
Hors ligne
Combien de personnes écrivent en même temps dans la base ?
Guillaume.
Hors ligne
les fichiers sont écrits en séquentiel.
On a 4 programmes qui tournent en simultané (les 3 autres ne font pas de COPY)
Hors ligne
OK, donc un seul programme écrit avec une seule connexion. Il y a peu de chances que vous arriviez à descendre la valeur des écritures de backend, ce qui en soit n'est pas une catastrophe. Il se ralentit lui-même, c'est tout.
Guillaume.
Hors ligne
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
Hors ligne
Bonjour,
Je pense que la bonne réponse est :
seule les connexions qui font des tris utilise une quantité de mémoire inférieure ou égale à work_mem
Cordialement,
Cordialement,
Sébastien.
Hors ligne
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.
Hors ligne
non elle indique que tout ça ne doit pas être supérieur à la RAM disponible sous peine d'écrouler les performances (swap).
D'ailleurs pour être plus précis :
"seule les connexions qui font des tris utilise une quantité de mémoire inférieure ou égale à work_mem" >> pour chacune des connexions. Les work_mem s'ajoutent donc avec un maximum qui est max_connection*work_mem. Et ça peut aller très vite d'où l'importance de bien caliber le couple "max_connection/work_mem".
Cordialement,
Sébastien.
Hors ligne
Postgres.0 : cette formule (aucune idée d'où vous la sortez) est extrêmement approximative. Maintenant, pour être franc, toute formule est approximative. Tout dépend de l'activité des processus et de leur nombre.
Ne serait que pour revenir à work_mem. Sébastien dit que "Les work_mem s'ajoutent donc avec un maximum qui est max_connection*work_mem.". Non, c'est faux. Un même processus peut utiliser plusieurs fois work_mem si le plan d'exécution de sa requête contient plusieurs tris et/ou hachages.
Guillaume.
Hors ligne
Postgres.0 : Non, c'est faux. Un même processus peut utiliser plusieurs fois work_mem si le plan d'exécution de sa requête contient plusieurs tris et/ou hachages.
et oui encore un petit détail qui peut avoir son importance.
Cordialement,
Sébastien.
Hors ligne
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.
Hors ligne
Pages : 1