Forums PostgreSQL.fr

Postgres.0

Membre

pg_stat_bgwriter PG 9.2

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+01

La 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 | 2

Merci d'avance

Dernière modification par Postgres.0 (07/11/2014 14:24:17)

gleu

Administrateur

Re : pg_stat_bgwriter PG 9.2

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.

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

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

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

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+01

checkpoint_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)

gleu

Administrateur

Re : pg_stat_bgwriter PG 9.2

Combien de personnes écrivent en même temps dans la base ?

---

Guillaume.

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

les fichiers sont écrits en séquentiel.
On a 4 programmes qui tournent en simultané (les 3 autres ne font pas de COPY)

gleu

Administrateur

Re : pg_stat_bgwriter PG 9.2

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.

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

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

ruizsebastien

Membre

Re : pg_stat_bgwriter PG 9.2

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.

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

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.

ruizsebastien

Membre

Re : pg_stat_bgwriter PG 9.2

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.

gleu

Administrateur

Re : pg_stat_bgwriter PG 9.2

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.

ruizsebastien

Membre

Re : pg_stat_bgwriter PG 9.2

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.

Postgres.0

Membre

Re : pg_stat_bgwriter PG 9.2

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.