Marc Cousin Meetup PostgreSQL Nantes 8 mars 2017 pg_stat_statements Marc Cousin Meetup PostgreSQL Nantes 8 mars 2017
Optimisation d’une base Les développeurs attendent la «danse du DBA», une série d’incantations magiques…
Danse du DBA : Paramètres OS (cache, read-ahead…), réseau Paramètres SGBD (cache, tris…) Plus de matériel, plus cher, scaling horizontal, vertical
Malheureusement Les gains sont habituellement faibles Surtout avec PostgreSQL Quand il y a des gains… souvent le problème est ailleurs 95% des gains de performances sont applicatifs Penser relationnel, pas procédural Ne pas multiplier les aller-retours à la base pour rien (ORM…) Ne pas faire de traitement inutile. La requête la plus rapide, c‘est celle qu‘on n‘exécute jamais
Cibler l’optimisation SQL est déclaratif (cache beaucoup de complexité) On brasse quelquefois des Téra-octets sans s‘en rendre compte Des dizaines, voire centaines de requêtes différentes dans une appli 95 % de ces requêtes ne posent pas problème Comment trouver les 5 % ?
Outillage log_min_duration_statement=0ms Tout tracer pgFouine puis pgBadger Fonctionne, mais quelquefois 1Go de logs toutes les 15s Volumineux Long à parser Pas de statistiques sur l’utilisation du cache par les requêtes
pg_stat_statements Vue en mémoire Entretenue par les sessions en temps réel Pas de dégradation de performances mesurable (<1%) 205 000 → 202 000 transactions par seconde pg_bench Pour chaque requête, nombreuses statistiques collectées
pg_stat_statements Pour chaque requête : Texte, nb appels temps total d’exécution,min/max/écart type nombre total d’enregistrements retournés accès au cache, volume de tri temps passé à faire des IO
pg_stat_statements Vraiment utilisable depuis PG 9.2 : normalisation de requêtes 9.4 : identifiant unique de requête (si search_path différent), requêtes stockées dans un fichier externe (et donc pas tronquées) 9.5 : ajout min_time, max_time, stddev_time
Utilisation shared_preload_libraries=’pg_stat_statements’ pg_stat_statements.max=10000 pg_stat_statements.track=top/all pg_stat_statements.track_utility=true/false Redémarrer (c’est une nouvelle zone de mémoire partagée) Create extension pg_stat_statements (où vous voulez)
utilisation Select … from pg_stat_statements Trier par : total_time desc (consomme des ressources et est lente) calls (ralentie par la latence réseau) shared_blks_hit (beaucoup d’accès au cache) temp_blks_read/write (beaucoup de tri) blk_read_time,blk_write_time : beaucoup d’IO pg_stat_statements_reset()
Limitations Pas d’exemple de requête (paramètres remplacés par ?) Pas d’historique (valeurs cumulées) ⇒ PoWA (PostgreSQL Workload Analyzer) Background Worker (capture automatique) Capture à intervalle régulier pg_stat_statements pg_stat_kcache : kernel. Temps système, cache système… pg_qualstat : prédicats hypopg : index hypothétiques, pour aide à l’indexation
Démo