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