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 !
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
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.
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.
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 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
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.
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 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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
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
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
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 <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/prices> <http://icann-registrars-life.dotandco.net/>
