Quelques personnes de Logilab ont assisté aux PGDay 2013 à Nantes. Voici quelques points qui nous ont marqués.

http://www.cubicweb.org/file/2932005/raw/hdr_left.png

Gestion de la capacité des ressources mémoire d'un serveur PostgreSQL par Cédric Villemain

Cédric Villemain nous a exposé plusieurs pistes d'investigation de la gestion mémoire de Postgresql.

On peut employer des outils Linux tels que vmstat, pmap, meminfo, numactl, mais aussi des outils spécifiques à Postgresql, tels que pg_stat (hit ratio), pg_buffercache (audit de la mémoire cache), pgfincore (audit du cache de l'OS).

Il faut mettre des sondes sur les tables et indexes critiques de manière à avoir une idée du fonctionnement "normal" pour ensuite détecter le fonctionnement "anormal". À Logilab, nous utilisons beaucoup munin, pour lequel plusieurs greffons Postgresql sont disponibles : munin pg plugins et pymunin.

Pour aller plus loin voir le support de présentation (1).

Les nouveautés de PostgreSQL 9.3 par Damien Clochard

Damien Clochard a fait une très synthétique présentation des fonctionnalités de la nouvelle version de PostgreSQL 9.3. Le cycle de release de Postgresql dure 1 an, donc la periode de beta est courte, il faut que la communauté soit impliquée pour tester rapidement. Damien en profite pour chanter les louanges de PostgreSQL, qui est, selon lui, le SGBD le plus dynamique au monde: 1 version majeure par an, 4-5 versions mineures par an, et un support de 5 ans des versions majeures.

Actuellement, cela signifie que 5 versions majeures sont maintenues (notamment en terme de sécurité) en parallèle : 8.4, 9.0, 9.1, 9.2, 9.3beta1. Notons donc que la version 9.3 qui sort bientôt sera donc supportée jusqu'à 2018.

http://www.logilab.org/file/150442/raw/elephant.png

Pour les nouveautés, difficiles à résumer, notons néanmoins :

  • des gains de performance,
  • des verrous possibles sur les clĂ©s Ă©trangères,
  • une gestion mĂ©moire plus fine,
  • la possibilitĂ© de faire des pg_dump en parallèle (--jobs),
  • scĂ©narios supplĂ©mentaires de rĂ©plication,
  • possibilitĂ© de "bascule rapide" en architecture rĂ©pliquĂ©e,
  • facilitation de mise en place d'un serveur clone (gĂ©nĂ©ration automatique du fichier recovery.conf),
  • vue matĂ©rialisĂ©es,
  • opĂ©rateurs supplĂ©mentaires pour JSON (citation "MongoDB avec la tranquilitĂ© (ACID)"),
  • les requètes LATERAL
  • extensibilitĂ© avec des processus supplĂ©mentaires permettant des opĂ©rations de maintenance, de supervision ou d'optimisation,
  • des backends supplĂ©mentaires pour les "Foreign Data Wrappers" (introduits en 9.1),
  • possibilitĂ© de sĂ©parer le fichier de configuration en plusieurs sous-fichiers (utile pour une pilotage par SaltStack par exemple).

Damien en a profité pour parler un peu des points forts prévus pour la version 9.4 :

  • simplification de la montĂ©e en charge,
  • rĂ©plication logique (rĂ©pliquer une seule table par exemple),
  • parallĂ©lisation des requĂŞtes (multi-coeurs),
  • stockages internes

En bref, concis et alléchant. Vivement qu'on ait cette version en production.

En attendant on a profité pour l'installer à partir des entrepôts Debian gérés par la communauté Postgresql.

Pour aller plus loin voir le support de présentation (2).

"Ma base de données tiendrait-elle la charge ?" par Philippe Beaudouin

Philippe Beaudoin a utilisé pour cette analyse une combinaison de pgbench (injection), et la table pg_stat_statements qui collecte les statistiques sur l'utilisation mémoire des requêtes : produit une table avec les query, nombre d'appels, temps passé, nombre de lignes, etc.

L'idée générale est d'établir un profil de charge transactionnel sur la production pour pouvoir comparer avec la pré-production ou la future plateforme.

Pour éviter de devoir copier les données de production (lent, problème de confidentialité, etc), il est conseillé d'utiliser "generate_series" pour remplir la base de données de données de test.

pgbench utilise des scenario TPC-B (Transaction Processing Performance Council Benchmarks) Pour chaque scénario (4 scénarios dans son exemple) on a une cible TPS (transaction par secondes). Il recommande de faire attention à ne pas modifier considérablement la taille de la base avec les scénarios (ex. trop de DELETE, ou trop d'INSERTs).

Un astuce pour charger le cache linux

find <files> -exec dd if='{}' of=/dev/null\;

Si on ne sait pas quels fichiers charger, on peut utiliser pg_relation_filepath(oid) FROM pg_class where relname like 'tbl%' pour trouver en SQL quels fichiers contiennent les données.

Nous avons demandé si un outil de type GOR (flux UDP de la production vers la pre-production ou le serveur de développement pour les requêtes HTTP) existait pour Postgresql.

http://www.logilab.org/file/150448/raw/gor.png

Réponse : Tsung contient un mode proxy qui permet d'enregistrer la production, ensuite de la rejouer en pre-prod, mais pas en mode live. À priori il serait possible de combiner plusieurs outils existant pour faire cela (pgShark ?). La problématique n'est pas simple notamment lorsque les bases de données divergent (index, series, etc).

Pour aller plus loin voir le support de présentation (3).

PostGIS 2.x et au delĂ  par Hugo Mercier

Nous avons trouvé la présentation réussie. Elle introduisait les concepts et les nouveautés de PostGIS 2.x. Ayant intégré des fonctionnalités de PostGIS à CubicWeb et travaillant un peu sur la visualisation en WebGL de données stockées dans CubicWeb+Postgresql, nous avons pu réfléchir à des possibilités de délégation de traitement à la base de donnée.

http://www.logilab.org/file/150441/raw/Screenshot%20from%202013-07-01%2010%3A30%3A00.png

Nous nous sommes aussi interrogés sur le passage à l'échelle d'applications web qui font de l'affichage de données géographiques, pour éviter d'envoyer au navigateurs un volume de données trop important (geoJSON ou autre). Il y aurait des architectures possible avec une délégation à Postgresql du travail de niveaux de zoom sur des données géographiques.

Pour aller plus loin voir le support de présentation.

blog entry of