Utilisation de PostgreSQL

Présentation au sujet: "Utilisation de PostgreSQL"— Transcription de la présentation:

1 Utilisation de PostgreSQL

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

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

4 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

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

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

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

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

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

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

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

12 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

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

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

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

16 Cas concurrentiel: l'anecdote
On détecte un problème sur un select for update et On remonte un bug surpgsql- 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 ?!

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

18 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

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

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

21 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

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

23 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

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

25 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

26 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)

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

28 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 »

29 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

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