Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je recharge actuellement les tables d'une base sur un nouveau serveur, et j'ai notamment 3 énormes tables (entre 30 et 220 Go).
Pour cela, j'utilise pg_restore, et me demande si je ne peux pas l'optimiser via les paramètres lié au bgwriter.
La requête ci-dessous donne les résultats suivants :
select * from pg_stat_bgwriter;
checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_backend_fsync | buffers_alloc | stats_reset
-------------------+-----------------+--------------------+---------------+------------------+-----------------+-----------------------+---------------+------------------------------
163 | 14 | 1464278 | 708767 | 3381 | 16915605 | 0 | 2443216 | 2012-04-06 23:56:32.97968+00
(quelques minutes après)
checkpoints_timed | checkpoints_req | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_backend_fsync | buffers_alloc | stats_reset
-------------------+-----------------+--------------------+---------------+------------------+-----------------+-----------------------+---------------+------------------------------
163 | 14 | 1539900 | 747803 | 3381 | 17133678 | 0 | 2491555 | 2012-04-06 23:56:32.97968+00
les paramètres bgwriter_delay, bgwriter_lru_maxpages et bgwriter_lru_multiplier sont configurés par défaut.
Si j'ai bien compris, on voit que buffers_backend est bien plus élevé que buffers_checkpoint, donc que le nombre de pages placées dans le cache par postgres (via pg_restore) est bien plus élevé que le nombre de pages placées par bgwriter.
Ai-je bien analysé ces paramètres? Si oui, je suppose que bgwriter n'a pas le temps de "vider" le cache par rapport à la quantité de données qui y est stockée (par l'opération de restauration de la table qui est en cours).
Du coup est-ce qu'au final cela ne ralentit pas l'écriture des données de cette table sur disque? Et comment l'optimiser? en diminuant bgwriter_delay qui est à 200ms actuellement? en augmentant le bgwriter_lru_maxpages?
Si on pouvait m'expliquer comment analyser les valeurs des champs de la table pg_stat_bgwriter, cela me permettrait d'y voir plus clair.
Merci d'avance en tout cas.
Hors ligne
Bonjour.
Je ne pense pas qu'un changement sur ces paramètres aient un résultat vraiment effectif sur le temps de restauration.
Il vaudrait mieux envisager d'augmenter le shared_buffers ou le maintenance_work_mem si vous en avez la possibilité. Vous pouvez également passer le paramètres full_page_writes to off le temps de la restauration et augmenter sensiblement le paramètre checkpoints_segment (aux environ de 16) pour gagner en rapidité.
Julien.
https://rjuju.github.io/
Hors ligne
Si j'ai bien compris, on voit que buffers_backend est bien plus élevé que buffers_checkpoint, donc que le nombre de pages placées dans le cache par postgres (via pg_restore) est bien plus élevé que le nombre de pages placées par bgwriter.
Euh non, ça ne veut rien dire, ça.bgwriter ne place pas de pages en cache.
Un gros buffers_backend indique que c'est surtout le processus postgres qui fait les écritures dans les fichiers de données. Un comportement à éviter autant que possible le reste du temps mais difficile à éviter dans le cas d'une restauration.
Les conseils habituels pour la restauration, c'est un maintenance_work_mem élevé (pour gagner en temps lors de la création des index), un checkpoint_segment/checkpoint_timeout élevé, un #
synchronous_commit désactivé (ie, à off). Comme vous êtes en 9.1, pensez à paralléliser la restauration (option -j de pg_restore), la valeur à associer à cette option dépendant du nombre de cœurs qui peuvent travailler à la restauration.
Guillaume.
Hors ligne
OK merci, c'est un peu plus clair maintenant.
En revanche, lorsque je lance le pg_restore pour une des grosses tables, voici le message d'erreur qui apparait :
pg_restore: [programme d'archivage (db)] erreur renvoyée par PQputCopyData : la connexion au serveur a été coupée de façon inattendue
Le serveur s'est peut-être arrêté anormalement avant ou durant le traitement de la requête.
Est-il possible que j'aie un timeout configuré quelquepart?
Merci!
Dernière modification par yoyostras (11/04/2012 08:51:48)
Hors ligne
Si vous vous connectez directement au serveur, non, pas de timeout. Par contre, si vous passez par un pooler qui est configuré pour couper les connexions trop longues, ou si vous passez par un routeur configuré de la même façon, ça peut poser problème. Mais en tout cas, la coupure ne vient pas de PostgreSQL.
Guillaume.
Hors ligne
Pages : 1
