Utilisation de PostgreSQL

Introduction et objectif Présenter un exemple d'utilisation Quelques pistes d'optimisation L'administration « simple » et quelques outils disponibles

Contexte Société Elma, filiale du groupe Maximiles Des programmes de fidélisation online: Des sites Web avec des base de membre, d'actes...

Cas d'utilisation de PostgreSQL Cas simple: Petite base de données (5Go) et application Web Cas avec volume: base plus importante (150Go) et application Web Cas concurrentiel: base, application web et scripts métier

Cas simple: Petite base de données 5Go de données sur disque Un serveur Web

Cas simple: les limites Montée en charge web Nombre de connexions à la base Les risques concurrentiels

Cas simple: Le Web La base est en général peu sollicitée Les serveurs web sont simples à ajouter

Cas simple: La base Paramétrer sa configuration PostgreSQL pour refléter sa configuration Web Le cache disque est pertinent

Cas simple: les risques Risque d'apparition de deadlock Ne pas voir les problème si la base grossie

Cas avec volume: base plus importante 150Go de données sur disque Un service web (plusieurs serveurs)

Cas avec volume: le Web Aller à l'économie « SQL » Requêtes efficaces Limiter leur nombre Cacher les données

Cas avec volume: la base Optimisation hardware: Raid 10 Utilisation de réplicat slave pour les lectures Partitionnement horizontal: Implications applicative L'application ne peut plus bénéficier d'un cache disque total

Cas concurrentiel Un serveur Web (peu de trafic) Un base (volume limité) Des scripts métiers => beaucoup de concurrence dans l'ensemble

Cas concurrentiel: Niveaux de verrouillage Obtenir la ressource nécessaire mais pas plus Faire ses modifications Valider (commit)

Cas concurrentiel: les deadlock Vérifier l'ordre des verrouillages Respecter la logique métier

Cas concurrentiel: l'anecdote On détecte un problème sur un select for update et On remonte un bug surpgsql- hackers@postgresql.org via un exemple simple 40 minutes après: Tom Lane détaille une analyse du bug 1h50 après un patch est commité. Il corrige notre problème Support platinium ?!

La performance Choix du hardware Analyse de l'activité Impact du système référentiel sur les performances

La performance: Hardware En fonction du volume de la base et de la sollicitation Des disques rapides (RAID 10) De la ram pour le cache Du CPU si il y a des calculs

La performance: mesures du hardware Graphe de l'utilisation de la Ram Graphe de l'utilisation des CPU

La performance: diagnostique de l'application Graphe de select/insert/delete Mesures en live

La performance: les contraintes référentielles Pour chaque insertion, vérification d'une ou plusieurs existences Délicat sur les tables avec beaucoup de « trafic » Parfois indispensable

Les outils autour de PostgreSQL Réplication: slony Sauvegarde: pg_dump et archive command Supervision: nagios Monitoring: grapher quoi ? Diagnostique: les outils, les pistes...

Slony Pas trivial à mettre en oeuvre Fonctionne très correctement Plutôt efficace Mise à jour des structures de table pas simple Contrôle de la synchronisation obligatoire

La sauvegarde avec pg_dump Simple à mettre en oeuvre Relativement simplement exploitable (grep,head,tail...) Long Sauvegarde « one-shoot »

La sauvegarde avec archive_command Simple à mettre en oeuvre Moins simple pour reexploiter les données: même version de PostgreSQL même architecture espace disque disponible Très rapide en continue. Long pour les phases initiales Sauvegarde continue

Supervision: Nagios L'outil de référence Beaucoup de plugin de contrôle disponibles Contrôles: Accès à la base Espaces disques et autres paramètres hardware Nombres de verrous Réplication pas trop en retard (slony)

Monitoring: Grapher quoi ? Le hardware L'activité: commit/rollback Les verrous lock Requêtes (stats_row_level=on) L'évolution du lag slony

Diagnostique: Voir ce qui « passe » Outil non intrusif: pgspy Utile pour une application type Web Permet de comprendre les erreurs applicative: Volume de requêtes anormal Requêtes répétées Diagnostique type « pompier »

Diagnostique: Voir ce qui « se passe » Cas du backend « très occupé »: Strace: déterminer l'activité système (read/write sur fd) Lsof: voir ce qu'il utilise Utiliser les tables pg_class pour savoir de quelles tables on parle

Conclusion Une base très solide Une communauté très active La réplication pas encore au « top » Questions ?