Vous n'êtes pas identifié(e).
Merci Dim pour le truc. J'essayerai de faire mettre ça en place. Ce qui pêche, ce sont surtout les écritures, je doute que ce paramètre influence ces opérations.
A priori, la solution donnée ne fonctionne pas dans tous les cas. On essaye d'avancer encore sur le sujet... En tout cas, ne vous attendez pas à des miracles. On va explorer la piste soulevée par Marc dès le retour de notre admin SAN.
Merci pour vos suggestions.
Salut Jean-Paul,
Je referai un retour si j'ai l'occasion de faire ces fameux tests de performances. N'hésitez pas à compléter ou à corriger les infos, je ne prétend pas que c'est la recette miracle. Néanmoins, les accès disques sont maintenant normaux.
A+ 
Ah super ! De rien, c'est avec plaisir.
Je vois où vous voulez en venir, mais j'ai le sentiment que ce n'est pas la bonne approche.
Voyez d'abord la section 8.5.1 de la doc: http://www.postgresql.org/docs/8.4/stat … etime.html
PostgreSQL devrait décoder de lui même une date de la forme DD/MM/YYYY. Il faudra néanmoins d'assurer que le paramètre datestyle soit positionné à 'iso, dmy' ou 'sql, dmy' (dans le postgresql.conf, ou dans la session avec SET datestyle='sql, dmy';). Vous devriez vous économiser un trigger.
Pour info:
postgres=# CREATE TABLE test (date_referentiel DATE);
postgres=# SHOW datestyle ;
DateStyle
-----------
ISO, DMY
(1 ligne)
postgres=# INSERT INTO test (date_referentiel) VALUES ('21/09/2011');
INSERT 0 1
postgres=# SELECT * FROM test;
date_referentiel
------------------
2011-09-21
(1 ligne)
J'ai toujours un truc à voir, sur la VM test, on est à 134Mo/s mais sur une autre on est à 276 Mo/s. Je ne sais pas s'il y a encore un facteur qui joue. Je dois démarrer un projet de bench pour s'assurer que les VM ont des perfs potables - bon, dans la vraie vie on l'aurait fait avant de passer en prod....
Bonjour,
Nous avions des problèmes de performance des accès disques sur des machines virtuelles. A priori, il y a quelques astuces que je rappelle ci-dessous:
- si l'hyperthreading est activé, toujours créer des VMs avec un nombre paire de vCPUs. Si non, ça s'effondre.
- toujours activer explicitement le support matériel de la virtualisation (extension Intel VT-X + EPT RVI ou son équivalent AMD le cas échéant). Ne pas laisser VMWare gérer ça en mode "Automatic".
En gros, nous sommes passés de vitesses d'accès dignes d'un Atari ST à des performances décentes (entre 200 et 300 Mo/s en écriture). Avant modification des confs, nous avions de bonnes performances lorsque les instances PostgreSQL n'étaient pas démarrées, mais des performances exécrables lorsque celles-ci étaient démarrées.
time dd if=/dev/zero of=toto.bin bs=8192 count=1000000
14849+0 enregistrements lus
14849+0 enregistrements écrits
121643008 octets (122 MB) copiés, 13,6363 seconde, 8,9 MB/s
real 0m13.730s
user 0m0.033s
sys 0m2.672s
Après:
time dd if=/dev/zero of=toto.bin bs=8192 count=1000000
119133+0 enregistrements lus
119132+0 enregistrements écrits
975929344 octets (976 MB) copiés, 7,27156 seconde, 134 MB/s
real 0m7.274s
user 0m0.062s
sys 0m1.645s
(La commande dd est interrompue par Ctrl-C ou manque d'espace).
A noter, la présentation de Jignesh Shah au sujet de PostgreSQL en environnement virtualisé: http://jkshah.blogspot.com/2011/09/runn … rtual.html
Et sans compter qu'un VACUUM FULL pourri les index
J'ai parlé trop vite, on ne trouve pas. Mais le SAN est innocent.
C'était une mauvaise conf de notre part. Voilà. 
J'ai un peu testé pgstatsinfo, ça me fait penser à AWR pour ceux qui connaissent. Il va plus loin que ce que tu peux récupérer avec nagios, mais un peu plus intrusif (nécessite une conf particulière, avec CSV Log, etc.). Je n'ai malheureusement pas encore eu le temps de le mettre en production. Et pareil, c'est adapté à de la Red Hat, il faut patchouiller pour que ça tourne avec un noyau récent.
Sinon, quelle est ton expérience est terme de performance pour une base virtualisée ? La perte est-elle importante ?
De notre côté, on a remarqué un truc bizarre sur une VM: lorsque PostgreSQL n'est pas lancé, on a de bonnes performances d'accès au SAN (genre 150 Mo/s et plus), lorsque PostgreSQL est lancé on arrive à 10 Mo/s grand max... Confirmé par l'ami Dédé et un SELECT count(*) sur une table qui n'était pas en cache.
Bonjour,
L'idée avec le PITR, c'est de faire une sauvegarde complète de la base (avec pg_start_backup) de manière régulière (mais pas tous les jours). Ensuite, vous sauvegarderez tous les jours les archives des journaux de transactions.
Si la base crash, vous pourrez alors reconstruire votre base en prenant la sauvegarde de T-3h et vous indiquez à PostgreSQL (via un fichier recovery.conf) qu'il trouvera les archives des journaux de transactions à tel endroit. Il s'en servira pour appliquer l'ensemble des modifications à votre base restaurée et la ramènera à l'instant T. Sous réserve évidemment que les fichiers soient disponibles.
J'appuie sur le conseil de kenrio qui est de relier votre outil de sauvegarde de fichiers avec le PITR. Ensuite, pour la sauvegarde des archives, vous n'aurez pas un volume très important à sauvegarder, comparativement à la volumétrie de la base.
Pour de plus amples informations sur la mise en oeuvre, je ne peux que vous renvoyer vers le manuel rigolo: PITR.
À noter la parution prochaine du "High Performance" en français chez Pearson:
* http://www.pearson.fr/livre/?GCOI=27440100863920
Il sortira normalement le 20 mai.
Et si vous lancez la requête sans le explain analyze ? (par curiosité). J'essayerai de voir demain si je peux vous aider, car je dois filer.
1.1) A priori non, vous pouvez vous en rendre compte avec un SHOW archive_command. Si la chaîne renvoyée est vide, rien n'est archivé.
1.2) archive_command permet d'indiquer une commande OS à utiliser pour archiver les logs (plus précisément, on les appelle des WAL). Ce n'est en aucun cas un répertoire de destination. Relisez la doc, c'est expliqué et vous trouverez une explication sur les jokers.
2.1) La 8.2 est encore maintenue. Vous trouverez les matrices de support ici
2.2) pg_log correspond à un répertoire dans lequel PostgreSQL va déposer ses traces (si vous voulez, là où vous trouverez votre alert.log Oracle).
Bonjour,
Vous nous présentez le résultat d'un EXPLAIN simple et d'un EXPLAIN ANALYZE. Le premier va simplement vous donner le plan d'exécution estimé, tandis que le second va vous donner le plan d'exécution estimé mais va y ajouter des statistiques d'exécution. Or, la collecte de ses statistiques à un coût qui fait grimper rapidement le temps d'exécution de la requête.
En fait, je ne comprends pas vraiment si vous fournissez les temps d'exécution des deux EXPLAIN ou bien les temps d'exécution réels de votre requête ?
Bonjour,
J'ai vu dans un autre sujet du forum que vous utilisez une version 8.2. Dans cette version, ce paramètre n'existe pas, il fait son apparition dans la version 8.3.
Donc en 8.2, il suffit de configurer correctement le paramètre archive_command pour que l'archivage soit actif: la doc explique comment faire.
Consultez les logs de PostgreSQL pour vous assurer que l'archivage est bien en place (vous pouvez forcer l'archivage en appelant la fonction pg_switch_xlog()).
Tout d'abord bonjour,
Votre index spatial vous permet d'accélérer les temps de réponses d'une requête spatiale, simplement en réduisant le volume de données qui doit être traité par les fonctions spatiales (les fameuses fonctions ST_* de PostGIS). Si vous n'en utilisez pas, la fonction spatiale, prenons par exemple ST_Intersect, devra parcourir toute la table et calculer si oui ou non la géométrie traitée fait partie des résultats ou non.
En fait, ces index de type GiST, permettent d'utiliser des opérateurs qui déterminent quels sont les objets dont les boîtes englobantes (bounding box) se recouvrent, et qui correspondent potentiellement aux objets que vous souhaitez retourner dans la requête, donc en gros de réduire le nombre de géométrie à traiter par les fonctions spatiales. Donc, dans la même requête, vous utiliserez une fonction spatiale (ST_*) pour discriminer plus précisément les résultats.
Votre requête comportera ainsi un opérateur && pour "forcer" l'utilisation d'un index - pour réduire les calculs ultérieurs -, ainsi qu'une fonction spatiale ST_*.
Vous trouverez des exemples d'utilisations dans la documentation officielle de PostGIS
gleu: oui, j'ai vraiment envie de faire quelque chose mais le temps manque toujours. Finalement je l'ai très peu lu, préférant la pêche aux moules à la lecture studieuse, mais c'est une véritable mine d'or d'informations.
PostgreSQL High Performance est sorti ! Je vais passer mes vacances à lire l'ebook, un comble ! 
Bonjour,
Simon Riggs annonce la sortie du livre qu'il a co-écrit avec Hannu Krosing sur l'administration des bases PostgreSQL 9.0 (mais le contenu s'appliquera très certainement aux versions précédentes). Pour l'instant il est en pré-commande sur le site de l'éditeur avec une sortie prévue en novembre.
Gregory Smith a, quant à lui, écrit un livre sur l'optimisation des bases PostgreSQL 9.0 (en fait couvre les versions 8.1 à 9.0) ; chez le même éditeur, en pré-commande avec une sortie prévue pour ce mois d'octobre.
Ces deux livres sont décrits à l'adresse suivante: http://www.2ndquadrant.com/postgresql-books/
La valeur de shared_buffers concerne les clients aussi, même si c'est un espace mémoire alloué par le postmaster. PostgreSQL s'en sert pour rendre accessible les blocs de données aux processus fils, modifier les lignes, etc.
Le mieux est probablement que je cite la documentation:
Si vous disposez d'un serveur dédié à la base de données, avec 1 Go de mémoire ou plus, une valeur de départ raisonnable pour ce paramètre est de 25% la mémoire de votre système. Certains cas peuvent nécessiter une valeur encore plus importante pour le shared_buffers mais comme PostgreSQL™ profite aussi du cache du système d'exploitation, il est peu probable qu'une allocation de plus de 40% de la mémoire fonctionnera mieux qu'une valeur plus restreinte.
Sans dire que c'est une erreur de positionner work_mem à 20Mo, je pense que c'est une valeur beaucoup trop haute pour une utilisation courante, surtout si le serveur se met à swapper. Avez-vous ce comportement pour toutes les sessions utilisateurs ? Ou est-ce que cela apparaît de manière ponctuelle ?
Pour revenir au point 3, attention, il n'y a pas de lien entre la taille d'un fichier WAL et de l'espace mémoire wal_buffers. Un fichier WAL fait nécessairement 16Mo. Pour schématiser, l'espace mémoire wal_buffers est plutôt un espace qui sert à PostgreSQL à stocker les données à inscrire dans les fichiers WAL ; plus cet espace est grand, plus PostgreSQL pourra écrire de données simultanément dans les WAL et vos performances en écriture n'en seront que meilleures.
Il n'y a donc aucune conséquence pour votre serveur en warm-standby.
Bonjour,
1) shared_buffers ne définie le max de mémoire globale alloué par PostgreSQL, mais la taille d'un espace mémoire partagé entre le postmaster (processus maître de Postgres) et les différents processus serveurs.
2) en gros, oui.
3) checkpoint_segments ne joue pas sur l'utilisation de la RAM mais va influer sur le nombre de WAL en ligne et par conséquent sur vos performances en écritures (en gros, plus il y en a, mieux c'est...). En revanche, un tampon est alloué, or espace shared_buffers, de la taille de wal_buffers et qui a une influence sur les perfs en écriture (par défaut, sa valeur est de 64 ou 128Ko, j'ai l'habitude de le passer à 1Mo, voire au-delà si le besoin s'en fait sentir).
4) depuis la 8.2 et sur un serveur dédié, on a tendance à utiliser 1/4 de la RAM. Dans votre cas 1Go. On peut aller au-delà évidemment.
Pour moi, le gros point noir dans votre conf est de passer work_mem à 20 Mo. Vous avez bien compris l'impact que cela a sur la consommation mémoire, cf question 2. Avez-vous réellement besoin d'allouer autant de mémoire pour les tris ? Par ailleurs, je conseille souvent aux développeurs de laisser work_mem à 1MB et de l'augmenter dynamiquement (ALTER SESSION SET work_mem = xxMB je crois) au besoin.
Si vous avez de réels problèmes de performance avec work_mem à 5MB, voyez en abaissant shared_buffers à 1Go, ou en augmentant la quantité de RAM physique du serveur.
En dehors de cela, votre configuration me semble bien faite.
Et pour enfoncer le clou vis à vis de MySQL, voici l'avis de Frédéric Brouard qui gagne sa vie plutôt avec SQL Server: http://blog.developpez.com/sqlpro/p9136 … /#more9136
