POSTGRESQL: Manager un serveur de base de données

Le
Etienne
Salut.

Bon mon problème du jour n'est pas relatif au SQL mais bel et bien à
l'administration PostgreSQL.

J'ai une charge assez importante sur mon serveur de base de données.

top - 10:01:55 up 70 days, 16:57, 0 users, load average: 16.59, 16.06,
16.06
Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.8%us, 0.5%sy, 0.0%ni, 97.1%id, 0.6%wa, 0.0%hi, 0.0%si,
0.0%st

Visiblement, c'est pas le CPU qui fait défaut.
Ce serait plutôt la mémoire ou les disques dur.

Ce que j'aimerai savoir c'est s'il existe une commande qui me permettrai
de savoir:
- qu'est ce que postgres est en train de faire a un instant précis
- quelle est la base de données qui consomme le plus de ressource a un
instant précis.

Bref quelques chose qui me permettrai de savoir pour aujourd'hui la
charge est montée en fléche alors que la semaine dernière tout allait bien !

Merci.
Etienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sebastien Lardiere
Le #22665841
On 10/11/2010 10:10 AM, Etienne wrote:
Salut.

Bon mon problème du jour n'est pas relatif au SQL mais bel et bien à
l'administration PostgreSQL.

J'ai une charge assez importante sur mon serveur de base de données.

top - 10:01:55 up 70 days, 16:57, 0 users, load average: 16.59, 16.06,
16.06
Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.8%us, 0.5%sy, 0.0%ni, 97.1%id, 0.6%wa, 0.0%hi, 0.0%si,
0.0%st

Visiblement, c'est pas le CPU qui fait défaut.
Ce serait plutôt la mémoire ou les disques dur.

Ce que j'aimerai savoir c'est s'il existe une commande qui me permettrai
de savoir:
- qu'est ce que postgres est en train de faire a un instant précis
- quelle est la base de données qui consomme le plus de ressource a un
instant précis.

Bref quelques chose qui me permettrai de savoir pour aujourd'hui la
charge est montée en fléche alors que la semaine dernière tout allait
bien !




Bonjour,

16 de load avec les CPU à 97% idle, c'est effectivement un beau score.

Pour savoir ce qui se passe dans PG, il y a la vue pg_stat_activity, qui
montre les requetes en cours d'execution. Des heures de jeux.

En plus de ça, en mettant ce qu'il faut dans les fichiers de logs,
l'analyse a posteriori par un outil comme pgfouine m'est d'une grande en
aide en production.

--
Sébastien
Etienne
Le #22666181
Le 11/10/2010 10:42, Sebastien Lardiere a écrit :
16 de load avec les CPU à 97% idle, c'est effectivement un beau score.



et oui en effet.
PS: c'était bien les IO dans mon cas aujourd'hui.

Pour savoir ce qui se passe dans PG, il y a la vue pg_stat_activity, qui
montre les requetes en cours d'execution. Des heures de jeux.



Super je vais regarder.
mais je suppose que cela me fonctionne que base par base !
Je vais regarder.

En plus de ça, en mettant ce qu'il faut dans les fichiers de logs,
l'analyse a posteriori par un outil comme pgfouine m'est d'une grande en
aide en production.



Ah oui. j'ai aussi un outil a moi, mais je vais regarder pgfouine.
Merci.

Etienne
Patrick Mevzek
Le #22668351
Le Mon, 11 Oct 2010 10:42:37 +0200, Sebastien Lardiere a écrit:
Visiblement, c'est pas le CPU qui fait défaut. Ce serait plutôt la
mémoire ou les disques dur.





Ce qui est le cas le plus fréquent pour un SGBDR. Le CPU est utile pour
les calculs style ORDER BY, mais il faut avant tout des disques rapides
et suffisamment de mémoire pour faire tenir dedans toute la base (si
possible).

Pour savoir ce qui se passe dans PG, il y a la vue pg_stat_activity, qui
montre les requetes en cours d'execution. Des heures de jeux.



Un simple ps auxww (ou équivalent) peut aussi être bien utile, car
PostgreSQL indique directement où il en est : idle, idle in transaction,
ou la requête SQL en train d'être exécutée...

Après faut des outils de suivi en continu évidemment, style MRTG, Nagios,
Munin, etc.

Pour traquer les problèmes d'I/O, sous linux, il y a la commande iotop
que je trouve très pratique.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
Publicité
Poster une réponse
Anonyme