Supervision et tendances

Transcription

1 12 Supervision et tendances Les performances de votre serveur de bases de données sont directement liées au bon fonctionnement du système d exploitation, et les performances de ce dernier sont liées directement au matériel utilisé. Pour que toutes ces pièces fonctionnent de concert, vous avez besoin d un bon outil de supervision. Une fois que vous arrivez à récupérer toutes les données importantes, un outil de graphes est essentiel pour visualiser et analyser les tendances générales de votre serveur. Ce type d outils peut vous aider à prévoir le moment où votre système va atteindre ses limites. Il peut aussi vous aider à détecter si les modifications ont été suivies d effet. Outils de supervision Unix Les outils de base pour la supervision sur Unix sont simples à utiliser et il est facile de montrer des exemples de bons et de mauvais comportements. C est la meilleure façon pour apprendre l intérêt de ces outils dans la supervision. Notez que les concepts dégagés ici et les exemples sont intéressants, y compris sur un système Windows. Le matériel, la façon dont les systèmes d exploitation fonctionnent et les concepts sur les performances ne sont pas différents. Plus loin dans ce chapitre se trouve un tableau de correspondance de terminologie entre les systèmes Unix et Windows.

2 334 Bases de données PostgreSQL Configuration d exemple Le serveur utilisé ici est le même que celui décrit au chapitre sur pgbench. Pour ces exemples, une petite base pgbench a été créée avec une échelle de 100 (ce qui tient facilement en mémoire), et le test mixte standard a été exécuté : $ pgbench -i -s 100 pgbench $ pgbench -j 4 -c 8 -T 300 pgbench Le test donne approximativement transactions/s. Des tests plus longs avec un TPS 1 plus bas seront aussi discutés dans le reste de ce chapitre. INFO L option -j n est disponible qu à partir de la version 9.0. Donc, si vous utilisez une version antérieure à la 9.0, oubliez la partie -j 4 pour la commande ci-dessus et les prochaines commandes. Les versions antérieures à la 8.4 ne gèrent pas non plus l option -T. Vous devrez passer par l option -t en lui précisant un argument suffisamment important pour que le test dure assez longtemps. Le serveur de tests a quelques spécificités au niveau des points de montage : pg_xlog se trouve sur /dev/sdf1 ; le répertoire des données se trouve sur /dev/md0 (un RAID 0 logiciel sous Linux ; les disques physiques sont sdc1, sdd1 et sde1). Il est important de connaître ces détails pour suivre les exemples iostat de ce chapitre. vmstat Si vous posez une question sur la liste de discussion pgsql-performance montrant que votre système pourrait être surchargé, le premier complément d informations qui vous sera demandé est de récupérer la sortie de la commande vmstat. Cette commande fournit la vue condensée la plus intéressante sur l activité du système. Comme en plus, il affiche toutes les informations sur une seule ligne, il est même possible de dégager une tendance à court terme en analysant un écran entier de lignes provenant de vmstat. Comme une ligne de vmstat est trop large pour tenir sur une page, nous allons découper chaque ligne en deux parties pour l instant. Par la suite, les exemples ne contiendront que les colonnes intéressantes. 1. Nombre de transactions par seconde.

3 Chapitre 12 Supervision et tendances 335 Voici la partie gauche du résultat de l exécution de vmstat alors qu un test avec pgbench est en cours, ce test ne consommant pas beaucoup de mémoire : $ vmstat 1 procs memory swap-- r b swpd free buff cache si so La signification des colonnes est donnée dans le manuel de vmstat : r. Nombre de processus en attente de temps processeur. b. Nombre de processus en veille non interruptible. swpd. Mémoire virtuelle utilisée. free. Mémoire inutilisée. buff. Mémoire utilisée pour les tampons. cache. Mémoire utilisée pour le cache disque. si. Nombre de lectures du swap sur disque par seconde. so. Nombre d écritures du swap sur disque par seconde. Vous verrez plus tard quelques exemples sur l interprétation des données de la partie procs et sur le comportement du système quand la mémoire disponible devient très petite. Ce qui n est pas montré ici, c est le comportement du système lorsqu il utilise du swap. Sur un serveur de bases de données, l utilisation du swap indique que la configuration mémoire de PostgreSQL est mauvaise. Il faut à tout prix réduire l utilisation de la mémoire. Du coup, il est important de surveiller les valeurs des colonnes si et so car une valeur différente de 0 pour ces deux colonnes mérite une investigation plus poussée. Sur Linux, le paramètre swappiness (qui a été abordé au Chapitre 4) peut avoir un effet important sur le fonctionnement du swap. La partie la plus intéressante de la sortie de vmstat se trouve en fait dans la partie droite, que voici : $ vmstat io system cpu bi bo in cs us sy id wa st

4 336 Bases de données PostgreSQL Voici les explications du manuel de vmstat sur ces colonnes : bi. Nombre de blocs lus par seconde à partir d un périphérique bloc. bo. Nombre de blocs écrits par seconde sur un périphérique bloc. in. Nombre d interruptions par seconde, y compris celles liées à l horloge. cs. Nombre de changements de contexte par seconde. us. Temps CPU passé sur du code en espace utilisateur. sy. Temps CPU passé sur du code en espace noyau. id. Temps CPU passé à ne rien faire (idle). wa. Temps CPU passé à attendre une entrée/sortie. st. Temps CPU récupéré par une machine virtuelle. Tous les temps CPU sont donnés en pourcentage. Par défaut, la version Linux de vmstat testée ici utilise des blocs de octets, ce qui signifie que les nombres affichés sont exprimés en kilo-octets par seconde. Du coup, la première valeur de la colonne bo, 38024, signifie que le débit d écriture était de 38 Mo/s sur cette période. La taille d un bloc pouvant varier suivant le système d exploitation utilisé, il est donc important de lire la section iostat pour obtenir plus d informations sur les tailles de blocs. Tous les exemples utilisant vmstat proposés ici collectent les données à un intervalle d une seconde (cela correspond au seul paramètre de la commande vmstat ci-dessus). Quelle que soit l intervalle utilisée, les statistiques fournies par vmstat sont des moyennes par seconde sur la période donnée. L interprétation en soi ne dépend pas de la période, cela ne fait que modifier la précision des données collectées. Un autre point à noter concerne la signification de la première ligne. Cette ligne représente le cumul de ces statistiques depuis son démarrage. La seconde ligne affiche en revanche les statistiques de l activité réalisée pendant la période indiquée en argument. Ainsi, si vous écrivez des scripts pour récupérer ces données et les traiter, il faut bien faire attention à ignorer la première ligne. Voici ce que donne vmstat sur une période de temps où pgbench était en cours d exécution et où le système est devenu moins réactif pendant deux secondes : procs ----io system cpu r b bi bo in cs us sy id wa st

5 Chapitre 12 Supervision et tendances 337 Notez la chute dramatique du nombre de changements de contexte (colonne cs) pour les deux lignes du milieu. Comme la charge générée par pgbench implique des changements de contexte, ces valeurs très basses représentent en fait une période pendant laquelle il ne se passe rien. Notez également que cette période correspond aussi à une hausse importante des attentes d entrées/sorties (colonne wa) et que les processeurs deviennent moins actifs. Ce comportement est significatif de problèmes de performances, c est-à-dire lorsque les disques sont le point de contention principal du système. iostat Les données fournies par vmstat correspondent à un cumul pour tous les disques du système. Si vous voulez obtenir des informations détaillées pour chaque unité de disque, vous avez besoin de iostat. Sur Linux, iostat n a pas la même définition du bloc que vmstat. Pour iostat, un bloc représente 512 octets, et non pas Cependant, il est possible de demander à iostat d afficher des valeurs en kilo-octets grâce à l option -k. Si vous ne le faites pas, il faudra prendre l habitude de diviser par 2 les valeurs fournies par iostat pour avoir des kilo-octets. Voici un exemple de la sortie de iostat : $ iostat Device tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda $ iostat -k Device tps kb_read/s kb_wrtn/s kb_read kb_wrtn sda Comme toutes les versions d Unix ne supportent pas l option -k avec iostat, les exemples montrés ici utilisent le bloc à 512 octets. Il faut donc diviser par deux les nombres affichés pour avoir l équivalent en kilo-octets. Il est généralement nécessaire de calculer la moyenne des données d iostat sur une période un peu plus longue que vmstat. Une période d une seconde pour vmstat vous donne un résumé de tous les disques du système. Une base de données PostgreSQL passe par différentes phases : 1. Tout de suite après un checkpoint : grosses écritures de blocs complets dans les journaux de transactions, un peu moins d écritures sur les fichiers de données car il y a moins d éviction de blocs modifiés dans le cache. 2. Entre les checkpoints (le précédent est terminé et la plupart des blocs utilisés ont déjà été écrits complètement dans les journaux) : la plupart des écritures touchent à la fois les fichiers de données et les journaux de transactions.