DUMP trop lent

lemjid · 30/09/2013 11:42:03

Bonjour,

Je constate depuis quelques jours sur une base postgresql8.4.7 la sauvegarde met 5h21min pour une base de ~40Go ce qui est énorme et aussi gênant pour des traitement qu'on est obligé de les scheduler plus tard.
J'ai fait quelques essaie de tuning comme l'augmentation du paramètre "maintenance_work_mem" vi cron avant le lancement de la sauvegarde. Je n'ai eu aucun résultat.
Voici qq information sur mon environnement et merci d'avance de votre aide.

MemTotal: 16432980 kB
PostgreSQL 8.4.7 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit "Linux xxxxxx 2.6.18-194.el5"
checkpoint_segments = 90
checkpoint_timeout = 5min
checkpoint_completion_target = 0.9
shared_buffers = 4000MB
temp_buffers = 8MB
work_mem = 1000MB

Pour la partie système je n'ai pas rajouté l'option (noatime) dans /etc/fstab pour les FS de la base de donnée. Si ceci pourra me faire gagner du temps sur la sauvegarde je le ferai.
Merci d'avance pour votre aide.

B.LEMJID

gleu · 30/09/2013 14:25:38

Il n'y a pas vraiment de paramètres dans postgresql.conf pour accélérer une sauvegarde. Elle utilise déjà toute la puissance du serveur. Avez-vous regardé ce qui vous bloquait ? CPU ? disque ?

lemjid · 01/10/2013 14:50:23

Bonjour Guillaume,

Merci beaucoup pour l’intérêt que vous avez accordé à mon post.
Je me doute bien que pour les performances postgresql c'est une association de plusieurs paramètres dans le fichier conf de plus les caractéristiques matériels et logiciels de la machine hébergeant la base...

Réponse à votre question je n'ai pas remarqué par rapport aux graphs que j'ai prélevé une saturation mémoire ou cpu, en revanche j'ai eu jusqu’à 237 locks "granted à true" dans la vue pg_loks. Ci après le query:
SELECT 'locks' AS locks,
(SELECT count(*) FROM pg_locks WHERE granted=true) AS granted,
(SELECT count(*) FROM pg_locks WHERE granted=false) AS waiting;
Juste pour ne pas perdre le nord. J'ai essayé de faire mon mieux pour investiguer et solutionner le problème, peut être j'ai fait fausse route...! J'aimerai bien si vous pouvez m’aiguiller pour être sur le bon chemin et ainsi atteindre le but.
D'avance merci.

gleu · 01/10/2013 16:08:37

Le fait que vous ayez des verrous pendant le dump est normal. PostgreSQL s'assrange juste pour que les objets en cours de sauvegardes (tables, fonctions, vues, etc) ne soient pas supprimables pendant la sauvegarde.

lemjid · 01/10/2013 22:58:00

Alors quels sont les pistes ou les paramètres qu'il faut explorer STP.

lemjid · 02/10/2013 10:37:17

Voici un échantillon du log bgwriter:
select 'bgwstats' as bgwstats,
checkpoints_timed,
checkpoints_req,
buffers_checkpoint,
buffers_clean,
maxwritten_clean,
buffers_backend,
buffers_alloc
from pg_stat_bgwriter
bgwstats 2329 9 1005961 9468 83 835438 35146557
bgwstats 2329 9 1005961 9468 83 835438 35146599
bgwstats 2329 9 1005961 9468 83 835438 35146599
bgwstats 2329 9 1005961 9468 83 835438 35146599
bgwstats 2329 9 1005961 9468 83 835438 35146599
bgwstats 2337 9 1007655 10449 89 835561 36007367
bgwstats 2337 9 1007655 10449 89 835561 36104104
bgwstats 2342 9 1007895 10449 89 835569 36975411
bgwstats 2342 9 1007895 10449 89 835569 36981076
bgwstats 2343 9 1008419 10449 89 837324 37027722
bgwstats 2343 9 1008419 10449 89 837538 37031873
bgwstats 2358 9 1011383 10450 89 837630 38713533
bgwstats 2358 9 1011383 10450 89 837630 38713533
bgwstats 2358 9 1011383 10450 89 837630 38713533

Bien à vous

gleu · 02/10/2013 11:25:03

> Alors quels sont les pistes ou les paramètres qu'il faut explorer STP.

Déjà demandé plus haut, consommation CPU ou disque ?

lemjid · 02/10/2013 18:03:35

Bonjour,
Voici aussi un échantillon de mpstat:
02:18:32 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
02:19:02 all 6.25 0.00 0.29 3.51 0.00 0.11 0.00 89.84 1935.68
02:19:02 0 0.03 0.00 0.07 0.10 0.00 0.00 0.00 99.80 1000.37
02:19:02 1 0.03 0.00 0.03 0.00 0.03 0.03 0.00 99.87 67.49
02:19:02 2 0.03 0.00 0.00 0.13 0.00 0.00 0.00 99.83 1.77
02:19:02 3 0.03 0.00 0.07 0.00 0.00 0.03 0.00 99.87 62.29
02:19:02 4 6.30 0.00 0.77 27.22 0.00 0.70 0.00 65.01 197.07
02:19:02 5 8.93 0.00 1.30 26.63 0.00 0.70 0.00 62.43 239.68
02:19:02 6 0.57 0.00 0.00 0.00 0.00 0.00 0.00 99.43 8.97
02:19:02 7 2.00 0.00 0.07 0.00 0.00 0.00 0.00 97.93 96.10
02:19:02 8 45.15 0.00 0.63 0.30 0.00 0.03 0.00 53.88 0.00
02:19:02 9 0.37 0.00 0.10 0.03 0.00 0.03 0.00 99.47 64.32
02:19:02 10 9.03 0.00 0.20 0.03 0.00 0.00 0.00 90.73 1.43
02:19:02 11 2.80 0.00 0.07 0.33 0.00 0.10 0.00 96.70 62.19
02:19:02 12 0.07 0.00 0.13 0.60 0.00 0.00 0.00 99.20 2.00
02:19:02 13 23.10 0.00 0.47 0.87 0.03 0.13 0.00 75.40 64.95
02:19:02 14 1.23 0.00 0.00 0.00 0.00 0.00 0.00 98.77 1.93
02:19:02 15 0.23 0.00 0.70 0.00 0.00 0.07 0.00 99.00 65.12

et ce log pour iostat:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 9.57 410.40 533.33 12312 16000
sda2 4.60 320.00 554.53 9600 16636
sdg 9.33 473.33 525.33 14200 15760
sdg2 21.37 773.60 587.47 23208 17624
sdm 8.87 416.53 522.67 12496 15680
sdm2 4.80 74.27 526.40 2228 15792
sds 9.10 404.27 587.60 12128 17628
sds2 6.13 536.67 500.53 16100 15016
sdu 0.03 0.27 0.00 8 0
dm-0 575.13 1704.53 2168.93 51136 65068
dm-2 575.13 1704.53 2168.93 51136 65068
dm-3 2.67 0.00 10.67 0 320
dm-4 33.83 1704.80 3.60 51144 108
dm-5 517.87 0.00 2071.47 0 62144
dm-8 0.50 0.00 2.00 0 60
dm-9 0.30 0.00 1.20 0 36
dm-10 0.60 0.00 2.40 0 72
dm-11 13.63 0.00 54.53 0 1636
dm-12 1.40 0.00 5.60 0 168
dm-15 4.37 0.00 17.47 0 524
avg-cpu: %user %nice %system %iowait %steal %idle
6.66 0.00 0.23 0.45 0.00 92.66

Merci encore pour votre attention.

gleu · 02/10/2013 21:20:13

Le CPU n'a pas l'air très occupé. Par contre, niveau disque, les périphériques dm-0, dm-2, dm-4 et dm-5 sont très demandés (env. 1,7 Mo/sec en lecture, et 2,1 Mo en écriture). Ce qui n'est pas énorme non plus.

lemjid · 03/10/2013 07:00:51

En effet et ce que me rend vraiment dingue, car je ne voit pas la raison de mettre tout ce temps pour le dump. De plus via un cron j'augmente la valeur de "maintenance_work_ment" à 6GB à cette plage de dump mais ça n'a strictement rien donné et je n'ai presque rien gagné en temps!! Faut il arrêter toutes le connexions même celles qui font du "select" à cette période et ne laisser que le pg_dump travailler?

lemjid · 03/10/2013 10:58:20

Je pense juste à une chose.
Dans la base postgresql il existe des BLOB, J'ai juste voulu faire un "\dl" sur cette base et ça met un temps fou pour répondre!
Voilà ce que j'ai comme info sur les BLOB:
=# select count(*) from pg_largeobject ;
count
----------
12198724
=# select sum(length(lo.data)) from pg_largeobject lo;
sum
------------
1000308488
(1 row)
Comme j'ai fait ce que j'ai pu au niveau de la base et la configuration et je n'ai rien trouvé d'anormale. A premier vu aussi Guillaume me dit presque la même chose (pour l'instant) je me demande si ce n'est pas ces vilains de BLOBs qui font que pg_dump met ce temps fou?
Merci d'avance pour votre réponse.

gleu · 03/10/2013 20:18:34

Pas très étonnant pour le maintenance_work_mem, il ne sert à rien sur le pg_dump.

Pour les Large Objects, vous avez certainement raison. PostgreSQL doit les convertir en séquence d'échappement si vous utilisez le format plain (SQL, texte). Utilisez un format binaire, ça sera beaucoup plus rapide.

lemjid · 03/10/2013 21:50:07

Pour le maintenance_work_mem, vous avez entièrement raison c'est utile pour le pg_restore mais dans le doute! je l'avait fait.
Absolument pas pour le format du dump j'utilise le format custum.
j'utilise ça comme commande:
pg_dump -Fc $DB > /répertoire_destination/$DB-$DATE.dump.
Voyez vous la casse tête?

gleu · 03/10/2013 22:54:01

Je vois surtout que vous n'allez pas pouvoir améliorer la vitesse de création d'un dump.

lemjid · 04/10/2013 05:55:07

C'est un comportement normale de postgresql!? plus de 5h pour 40 Go de donnée? C'est possible de m'expliquer pour quoi? Que faire alors car surtout on est devant une évolution de la base. il n y a pas d'autre alternative? Exemple migration vers V9.X ...

gleu · 04/10/2013 14:25:29

Sans avoir les mains sur le serveur, c'est difficile de répondre à vos questions. Si une majorité des 40 Go sont des objets binaires, oui, ça peut être normal. Est-ce qu'une mise à jour de PostgreSQL améliorerait les choses, c'est possible. En tout cas, vous pouvez très facilement tester ça vous-même.

gleu · 04/10/2013 15:48:43

Je viens de penser à un truc. Si vous utilisez -Fc et que vous avez de la place disque, désactivez la compression. Il y a de fortes chances qu'elle ne serve pas à grand chose avec des objets binaires et qu'elle vous prenne beaucoup de temps.

lemjid · 04/10/2013 23:45:13

Merci Guillaume pour la réponse.
En effet le jeudi j'avais ajouté l'option -Z 2 car à ma connaissance postgresql compresse le fichier de sauvegarde avec pg_dump. La valeur de compression par défaut est de 6 sur un échelle de 9.
C'est vrai que j'ai gagné énormément sur le temps de la sauvegarde mais j'ai eu un fichier beaucoup plus grand. Cette option à résolu partiellement mon problème vu que le fichier dump est grand. Aussi je reste toujours sur ma faim.

En revanche que voulez vous dire par désactiver la compression? est ce que c'est l'option (-Z 0) ou il y a une autres astuce?
Faut il changer la commande pg_dump c.a.d d'autres options et autre format de fichier? lequel?
Est ce que par cela on peut dire que postgresql ne peut pas faire mieux? et que mon sujet est clos!?

Merci encore pour le temps que vous m'avez accordé merci pour votre disponibilité et réactivité.

gleu · 04/10/2013 23:50:22

> En revanche que voulez vous dire par désactiver la compression? est ce que c'est l'option (-Z 0) ou il y a une autres astuce?

C'est en effet l'option -Z0.

> Faut il changer la commande pg_dump c.a.d d'autres options et autre format de fichier? lequel?

Non, c'est l'option -Z0.

> Est ce que par cela on peut dire que postgresql ne peut pas faire mieux? et que mon sujet est clos!?

Faire mieux que quoi ? encore une fois, de telles questions si ouvertes ne peuvent pas vraiment avoir de réponses.

lemjid · 05/10/2013 16:42:26

Désolé d'être imprécis.
Je veux dire par cela: Sans rajouter l'option "-Z" comment peut on faire un temps correcte et aussi dump pas trop volumineux.

gleu · 10/10/2013 13:29:40

Vous pouvez essayer de configurer zone_reclaim_mode à 0 (attention, paramètre linux, pas PostgreSQL).

lemjid · 10/10/2013 14:48:17

Non je ne l'ai pas fait. De plus ce paramètre n'existe même pas dans mon "sysctl.conf" faut il le rajouter?
ça mérite d'être testé. Je le ferai sur un environnement d'étude et je vous communiquerai le résultat.

Merci davance

rjuju · 10/10/2013 14:55:36

Oui, en spécifiant bien le nom complet (vm.zone_reclaim_mode).

lemjid · 10/10/2013 17:55:16

OK! Julien,

Je rappel juste ma version OS et Postgresql pour être sûre.
PostgreSQL 8.4.7 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit "Linux xxxxxx 2.6.18-194.el5"

gleu · 10/10/2013 22:19:25

À priori, pour un collègue, ça a fait des miracles. J'avoue que je suis intéressé par le résultat.

#1 30/09/2013 11:42:03

DUMP trop lent

#2 30/09/2013 14:25:38

Re : DUMP trop lent

#3 01/10/2013 14:50:23

Re : DUMP trop lent

#4 01/10/2013 16:08:37

Re : DUMP trop lent

#5 01/10/2013 22:58:00

Re : DUMP trop lent

#6 02/10/2013 10:37:17

Re : DUMP trop lent

#7 02/10/2013 11:25:03

Re : DUMP trop lent

#8 02/10/2013 18:03:35

Re : DUMP trop lent

#9 02/10/2013 21:20:13

Re : DUMP trop lent

#10 03/10/2013 07:00:51

Re : DUMP trop lent

#11 03/10/2013 10:58:20

Re : DUMP trop lent

#12 03/10/2013 20:18:34

Re : DUMP trop lent

#13 03/10/2013 21:50:07

Re : DUMP trop lent

#14 03/10/2013 22:54:01

Re : DUMP trop lent

#15 04/10/2013 05:55:07

Re : DUMP trop lent

#16 04/10/2013 14:25:29

Re : DUMP trop lent

#17 04/10/2013 15:48:43

Re : DUMP trop lent

#18 04/10/2013 23:45:13

Re : DUMP trop lent

#19 04/10/2013 23:50:22

Re : DUMP trop lent

#20 05/10/2013 16:42:26

Re : DUMP trop lent

#21 10/10/2013 13:29:40

Re : DUMP trop lent

#22 10/10/2013 14:48:17

Re : DUMP trop lent

#23 10/10/2013 14:55:36

Re : DUMP trop lent

#24 10/10/2013 17:55:16

Re : DUMP trop lent

#25 10/10/2013 22:19:25

Re : DUMP trop lent

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux