Vous n'êtes pas identifié(e).
Je ne manquerai pas de vous communiquer le résultat. Il faut juste me donner le temps pour demander un environnement de test identique. Dès que je l'aurai je vous fait part des résultats.
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"
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
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.
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é.
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 ...
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?
Paru sur le web l'encouragement de l'état au développement des OS, BDD et progiciels open source dont POSTGRESQL
http://www.commentcamarche.net/news/586 … amenardsur
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.
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?
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.
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
Alors quels sont les pistes ou les paramètres qu'il faut explorer STP.
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.
Bonjour "mortimer",
Je veux bien participer à ce sujet malheureusement pas pour apporter une solution mais pour demander qq chose (car moi aussi je galère derrière les perfs). Je voudrai savoir comment faire pour les FS en ram car ce sujet m’intéresse.
Bien à vous
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
Bonjour,
Je suis d'accord avec Julien pour md5.
Pour la connexion à distance il faut peut être penser à désactiver le FW sur le serveur de la base de donner ou autoriser la machine à se connecter dessus en plus la vérification du fichier pg_hba.conf s'il est bien fait.
Pour finir le message d'erreur sera la moitié de la réponse.
Bien à vous
Bonjour Guillaume,
T'as raison car j'ai oublier (désolé) de préciser que c'est une architecture HA (streaming replication) avec deux machines master/slave. Donc j'ai fait pg_basebackup pour restaurer les données sur l'un des nœuds.
En revanche peux tu (ou julien) me dire ce que je dois chercher dans la sortie de la commande "dmesg"?
Bien à vous
Bonjour, merci rjuju!
Comme indiqué plus haut j'ai supprimer et recréer le cluster postgres via initdb et restaurer les données via pg_basebackup. Pour plus de précision c'est une VM qui ecrit sur du raid 5, 3 disques (pas bien je sais mais je ne suis pas décideur) bref. L'OS redhat6. je na sais pas s'il faut faire un dmesg ou un "tw_cli" moi aussi je me penche sur un pbm matériel mais j'aimerai investir tout les pistes concernant le SGBDR postgres. car la partie système
n'est pas ma responsabilité pourtant ça m’intéresse fortement.
Pour dmesg j'avoue que je ne sais pas tout lire mais si tu pourras m'aiguiller quel information devrai je chercher ça m'aidera énormément.
merci d'avance
Bonjour,
Je me rend compte quand j'ai voulu j'ai voulu créer des extension (postgis+dblink) sur une nouvelle base créée sous postgres d'un message:
"ERROR: could not read block 43 in file "base/xxx/yyy" : read only 0 of xxx bytes" de plus je ne peux même pas faire un vacuum full su cette base ni sur la base (postgres). Pour les autres base je peut faire vacuum full mais pas celui ci. Sur internet ils parlent de bug et ils disent de faire une restauration chaose que j'ai faite après un "initdb" en vain.
Pour le bug je ne crois pas car j'ai fait la même opération sur un environnement identique (version linux 'redhat6' et postgesql) je ne sais pas si qq à eu une même galère et qui pourra m'aider.
Merci d'avance
Merci Guillaume pour ta réponse et pour ta disponibilité.
J'aurai bien aimer avoir une valeur même à la louche hélas. Il me reste qu'a demander de doubler l'espace du FS.
Chose aussi que je ne comprends pas c'est que en appliquant la règle du nombre de fichiers "wal" (3 * checkpoint_segments + 1). Le résultat n'est pas bon chez moi car j'ai 82 fichiers wals seulement !? Dois je toucher à un autre paramètre ou c'est un fonctionnement normal?
Merci encore
Merci guillaume pour votre réponse,
Pour information, voilà ce que j'ai comme paramètres:
checkpoint_segments = 40
checkpoint_timeout = 5min ==> (valeur par défaut).
Une question: c'est quoi la proportion de la taille des FS $PG_XLOG et $ARCH par rapport à la taille de la base que j'ai? Y a-t- il une formule de calcul et une valeur (à la louche) à me communiquer SVP.
Bien à vous
Bonjour,
Je rencontre un problème lors de la restauration d'une base sur un environnement en streaming_réplication. Lors de la restauration d'une des bases utilisant pg_restore, je me rend compte que mes FS $PG_XLOG et $ARCH sont plein à 100% quelques minutes après le lancement de pg_restaure et du coup la restauration échoue.
Questions:
Est ce que je devrai arrêter l'esclave et modifier les paramètres d'archives dans postgresql.conf et après je restaure l'esclave avec pg_basebackup?
Faut il piocher dans les paramètres postgresql.conf pour résoudre ce problème? Voir s'il faut voir autre choses? ou tout simplement augmenter la taille des FS $PG_XLOG et $ARCH? de combien?
Voici qq information:
*PostgreSQL 9.1.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit
*l'archivage des wal s'effectue dans un FS du serveur esclave.
*archive_cleanup est en place.
* Je possède 12Go de ram sur le servaur maître et le shared_buffers=3GB.
* La base en question fait 22Go
* le FS pg_xlog fait 8Go ainsi que le FS des archives.
* La totalité des données Postgresql sur cette machine est de ~38Go.
Merci d'avance pour votre aide.
Merci Guillaume,
Je vais peut être vous surprendre!!! j'ai refait un test en suivant ceci:
1- sauvegarde barman.
2- arrêt de la base.
3- suppression du répertoire $PGDATA.
4-crée le répertoire $PGDATA avec le user barman comme owner.
5- recover barman.
6- Modifie l'owner $PGDATA pour postgres (conserver les droits adéquates sur les fichiers et répertoires dans $PGDATA).
7- Lance postgres avec "pg_ctl start" (un test avec modification paramètre "archive_command" avant demarrage et sans changement avant démarrage).
Résultat ça marceh!!!!
Je demande de ne pas prendre argent cash ce que je fait car il faut que je test encore avec ce que tu m'as demandé en revanche si tu pourras me donner plus de détails sur le contenu du fichier "recovery.conf" de plus les étapes.
*Concernant le rsync je suis bien en version:
Installed Packages
Name : rsync
Arch : x86_64
Version : 3.0.6
Release : 9.el6
Donc pas de souci de ce côté ainsi que les autre préconisation, j'ai fait en sorte de suivre minutieusement ce qui à été demandé dans la doc officielle.
Bien à vous.
