Quelques personnes de Logilab ont assisté aux PGDay 2013 à Nantes. Voici quelques points qui nous ont marqués.
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.
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.
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.
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.