L'objectif principal de pgFouine est de permettre aux développeurs et aux administrateurs de bases de données PostgreSQL de comprendre l'activité de leurs applications et de leurs bases de données.
Les principales fonctionnalités sont les suivantes :
- génération de rapports tels la répartition des requêtes par type, la liste des requêtes qui prennent le plus de temps ou la liste des erreurs ;
- génération de graphiques permettant d'avoir une vision horaire de l'activité de la base ;
- l'analyse de logs des commandes VACUUM VERBOSE (nouveau) ;
- la génération de fichiers XML de sessions pour Tsung, un outil de tests de charge qui supporte entre autres PostgreSQL (nouveau).
- mener des campagnes d'optimisation ponctuelles : on active les logs durant un moment, on génère un rapport et on optimise les requêtes,
- suivre l'activité quotidienne de la base en générant des rapports quotidiens (requêtes les plus lentes, erreurs...).
Détails des nouveautés
- Analyse des logs de VACUUM
Le VACUUM est l'opération de maintenance la plus importante pour une base PostgreSQL. Elle permet de réclamer l'espace libre occupé par les lignes supprimées ou mises à jour. Cette opération est très importante et extrêmement coûteuse en terme de ressources et provoque parfois une quasi indisponibilité de la base.
Cette opération peut être mise en oeuvre de différentes manières : VACUUM, VACUUM FULL ou utilisation du démon autovacuum.
Le choix entre ces différentes stratégies n'est pas toujours simple et le choix de la périodicité n'est pas non plus évident. PostgreSQL permet d'obtenir une sortie détaillée de cette opération en utilisant le mot clé VERBOSE. Cette sortie peut être conséquente pour des grosses bases (sur certains de nos serveurs, nous obtenons des sorties de 10 000 lignes) et il est alors quasi impossible de l'analyser.
pgFouine permet désormais d'analyser cette sortie et de présenter les informations de manière exploitable, permettant d'affiner la stratégie de VACUUM mise en oeuvre.
- Génération de fichiers de sessions pour Tsung
Tsung est un outil de test de charge écrit en erlang. Depuis sa version 1.2 annoncée ici-même, il dispose d'un plugin PostgreSQL.
La génération de fichiers de sessions à partir des logs permet d'envisager de construire des scénarios réalistes à partir des requêtes réelles de la base de production.
Cela permet de valider une montée en charge mais également une montée de version de PostgreSQL (mesurer les gains obtenus et vérifier la bonne exécution des requêtes).
- Projets
L'avenir proche est la compatibilité avec la version 8.2 de PostgreSQL prévue pour la fin de l'année et notamment la possibilité d'analyser les requêtes préparées, ce qui n'était pas possible avec la version 8.1.
La présence dans les distributions est également un axe de développement important. Le RPM de pgFouine devrait être proposé à l'intégration dans Fedora Extras dans les jours qui viennent. Un ebuild Gentoo est disponible ainsi qu'un paquet dans Mandriva Contrib.
Un développeur Debian serait le bienvenu afin de packager pgFouine pour Debian.
Les outils d'analyse de logs PostgreSQL
L'analyse des logs de PostgreSQL pour optimiser les requêtes a été popularisée par PQA (Practical Query Analyzer) avec une première version en mars 2004. Il était jusqu'alors difficile d'avoir une vision analytique des temps d'exécution des requêtes sur des grosses plate-formes (logs énormes et difficulté à ressortir l'information).
Après l'avoir utilisé pendant un moment au sein de ma société (un de mes collègues a d'ailleurs réécrit une bonne partie du parser pour qu'il puisse fonctionner correctement lorsqu'on exécute énormément de requêtes concurrentes), j'ai pris la décision de réécrire entièrement l'outil en tenant compte de l'expérience que nous avions accumulée grâce à notre utilisation de PQA et en corrigeant les problèmes que nous rencontrions (notamment une utilisation mémoire excessive qui le rendait inutilisable dans notre cas). Cette réécriture complète a pris forme sous le nom de pgFouine.
PQA n'est plus trop maintenu pour le moment. La dernière version, principalement basée sur les modifications apportées par mon collègue, est sortie en novembre 2005.
Depuis sa première version sortie en novembre 2005, pgFouine a énormément évolué et a vu ses fonctionnalités se diversifier. Pour la petite histoire, au sein d'Open Wide, nous l'utilisons également pour analyser les performances de génération des pages par PHP sur des serveurs Apache.
Dernier arrivé dans le monde des analyseurs de logs PostgreSQL, pglog-analyze a une approche différente et tend à aller beaucoup plus dans le détail et dans l'analyse du comportement de chaque requête. pglog-analyze offre ainsi une vision différente et complémentaire par rapport aux autres outils. Petit bémol cependant, sur des plate-formes très chargées, il nous arrive de traiter des fichiers de log de plus d'1 Go, et il devient alors difficile de se servir de cet outil car il utilise énormément de mémoire.
Pour être tout à fait complet, il faut également citer PostgreSQL Log Analyzer développé par le groupe SAMSE que je n'ai jamais eu l'occasion d'utiliser et dont la dernière mise à jour date de 2004.
Aller plus loin
- Site de pgFouine (577 clics)
- Projet hébergé sur PgFoundry (104 clics)
- Exemple de rapport de requêtes (196 clics)
- Exemple de rapport avec graphes (134 clics)
# Tout simplement...
Posté par TuxPierre . Évalué à 2.
Je vais donc de ce pas me plonger dans les rapports.
# Comparaison avec Oracle
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
- Qu'en est-il actuellement ?
- Manque-t-il encore des outils à Postgresql ?
Mon impression est que Postgresql est maintenant aussi mature que complet et que son utilisation professionnelle est très compétitive. Est-ce que je me trompe ?
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Les outils d'administration qu'ils soient libres ou propriétaires sont très complets. La communauté autour de PostgreSQL (principalement autour des listes de diffusion et du channel #postgresql sur freenode) est très active/réactive et les discussions sont en général de très bon niveau (ceci s'explique aussi par le fait que les débutants passent souvent par la case MySQL).
Côté support aux entreprises, que ce soit aux Etats-Unis (Red Hat, Command Prompt, EntrepriseDB ou Greenplum pour les datawarehouses et le business intelligence), au Japon, en Australie ou plus proche en France (que je connais personnellement, il y a au moins Dalibo et nous - Open Wide), des entreprises proposent du support/de l'hébergement autour de PostgreSQL.
L'avantage d'avoir plein d'entreprises différentes autour est que le projet n'est pas noyauté et est vraiment très ouvert.
PostgreSQL reste une des bases qui suit le mieux les standards et cela se sent dans l'utilisation quotidienne car tout est très logique et tombe en général sous le sens. C'est un des plus qui fait la différence avec un client (psql) très bien conçu, un EXPLAIN ANALYZE très détaillé qui permet de vraiment comprendre comment s'exécute une requête en vue de l'optimiser et tout plein de petites choses qui simplifient la vie au quotidien.
Pour prendre un cas concret, nous avons accompagné Cityvox (gros site d'informations sur les villes) dans leur migration d'Oracle vers PostgreSQL il y a plus d'un an maintenant et ils en sont plus que très satisfaits. Ca va plus vite, ça coûte _beaucoup_ moins cher et le fonctionnement est beaucoup plus transparent.
Il reste un point sur lequel Oracle a de l'avance, ce sont les solutions de clustering. Les solutions de réplication pour PostgreSQL sont maintenant matures mais il leur reste un sacré chemin avant d'atteindre ce que peuvent faire les solutions de type Oracle RAC.
En espérant avoir répondu à tes interrogations.
[^] # Re: Comparaison avec Oracle
Posté par Sha0 . Évalué à 1.
Merci
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
De manière plus générale au boulot, nous utilisons phpPgAdmin ( http://phppgadmin.org/ ) et aussi pgAdmin III ( http://www.pgadmin.org ) qui sont libres et assez classiques.
Pour les outils propriétaires, j'ai entendu des bruits et vu des screenshots mais nous ne les utilisons pas.
[^] # Re: Comparaison avec Oracle
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
Perso, le couple MySQL/PhPMyadmin me plait beaucoup quand même (facilité d'installation, d'utilisation, perf, documentation...) mais au moment de passer en prod, on passe à postgresql :D
http://about.me/straumat
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . Évalué à 6.
Pour ton "MySQL/PhPMyadmin (facilité d'installation, d'utilisation, perf, documentation...)", je dirai que c'est une question de goût :
* sous Linux, il est aussi facile d'installer l'un que l'autre ;
* pour l'utilisation, je trouve PostgreSQL beaucoup plus logique (mais c'est peut-être parce que je le pratique plus que MySQL depuis 2001) ;
* pour les perfs, cela dépend de la complexité des requêtes et s'il y a plus d'un utilisateur :) ;
* pour la documentation, je préfère celle de PostgreSQL (je trouve le moteur de recherche plus pertinent notamment et la doc globalement plus claire et moins touffue/bordélique).
[^] # Re: Comparaison avec Oracle
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
Pour Mysql, je suis d'accord (et je tiens à dire qu'on utilise postgresql plus souvent)
* Sous linux, apt-get install phpMyAdmin mysql apache et tu as aussi l'outil d'admin accessible à distance qui fonctionne .. :) mais c'est vrai que tu as aussi facilement postgresql et son outil d'admin facilement.
* l'utilisation.. question de goût, ça c'est clair
* perfs.. idem, c'est clair que ça dépend :)
* doc, jai souvent trouvé plus de choses sur MySQL quand j'avais des soucis que lorsque j'en avais avec Postgresql... La pire des bases la dessus est firebird... je trouve la doc et le support nul meme si le produit est bien.
Bref, on est d'accord sur le fait que postgresql est vraiment une belle bête :)
http://about.me/straumat
[^] # Re: Comparaison avec Oracle
Posté par Xavier Maillard . Évalué à 2.
[^] # Re: Comparaison avec Oracle
Posté par Xavier Maillard . Évalué à 1.
J'espère qu'un jour, l'entreprise pour laquelle je bosse ouvrira les yeux et pensera à PostgreSQL pour ses projets. Quand on voit que entre IIS et une solution type Apache, nous préférons IIS, je me dis que ce n'est pas pour demain...
[^] # Re: Comparaison avec Oracle
Posté par georgeswwbush . Évalué à 1.
néanmoins, c'est comme tout, rien n'est inné, il existe des formations et des société de service qui peuvent aider à utiliser ce produit de manière efficace.
[^] # Re: Comparaison avec Oracle
Posté par Xavier Maillard . Évalué à 0.
Franchement pour m'être approché d'une paire de BDD relationnelle, celle avec laquellle je n'ai jamais eu à me plaindre (jusqu'à présent) reste postgreSQL. Pour les autres, c'est du grand folklore (patches, bogues rarissime selon les hot line mais qui se produit quasiment quotidiennement, etc.) et ce avec ou sans l'aide des "ingés éditeurs" ou de leurs sbires de sous-traitants incompétents.
# Et sous MySQL ?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # Re: Et sous MySQL ?
Posté par Guillaume Smet (site web personnel) . Évalué à 1.
C'est pas grave :).
PQA jusque sa version 1.4 pouvait analyser des logs MySQL également donc cela fera peut-être ton bonheur.
Au départ, je pensais aussi que pgFouine évoluerait peut-être dans ce sens donc il était assez générique pour pouvoir accueillir MySQL (et ou n'importe quel autre SGBD). Au fur et à mesure, je dois avouer que quelques PostgreSQLismes se sont glissés dans le code. Ceci dit, l'effort ne doit pas être énorme pour les remettre à leur place.
Si tu as des logs MySQL bien parlants et variés qui ne sont pas confidentiels, je peux y jeter un oeil rapide, voir si cela peut se faire vite, Je vais avoir un peu de temps prochainement.
En fait, je m'étais dit que j'aurai probablement l'occasion au niveau du boulot de bosser dessus (cela me saoûle pas mal de faire du MySQL sur mon temps perso) mais pour l'instant, cela ne s'est pas présenté donc c'est resté comme ça.
S'il y a une demande et des gens pour fournir des fichiers de logs et faire des tests, ça peut s'arranger (note que je n'ai aucune idée de la tête d'un fichier de log MySQL donc je ne sais même pas s'il est possible de le faire :)).
La balle est donc dans ton camp :).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.