Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
C'est mon premier mail sur ce forum.
J'administre une base de données Postgresl 8.4 de 12 Go avec des centaines d'utilisateurs sur un serveur Ubuntu 10.04 LTS
Depuis quelques jours je constate une surcharge inhabituelle du serveur et j'ai du mal a identifier la cause.
J'ai essayé d'optimiser les paramètres de gestion de la mémoire comme indiqué sur cette page, car j'utilise le logiciel Dynacase :
-> http://www.dynacase.org/dynacase/instal … postgresql
Mais à priori, cela n'a pas changé grand chose.
Je suis en particulier étonné du nombre important de requêtes en attentes comme le montre pg_top et du 56.2% de iowait :
ast pid: 13864; load avg: 2.05, 2.85, 3.53; up 71+01:19:56 10:01:56
9 processes: 1 running, 5 sleeping, 3 uninterruptable
CPU states: 37.8% user, 0.0% nice, 6.1% system, 0.0% idle, 56.2% iowait
Memory: 1920M used, 92M free, 28M buffers, 1561M cached
Swap: 10M used, 5885M free, 4168K cached
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
13840 postgres 20 0 542M 186M disk 0:04 6.23% 33.30% postgres: freedomowner freedom ::1(44041) SELECT
13852 postgres 20 0 543M 21M sleep 0:00 1.57% 13.36% postgres: freedomowner freedom ::1(44053) INSERT
13861 postgres 20 0 546M 24M disk 0:00 0.65% 7.78% postgres: freedomowner freedom ::1(44061) INSERT
13249 postgres 20 0 667M 98M disk 0:03 1.35% 1.60% postgres: autovacuum worker process freedom
13862 postgres 20 0 539M 5792K sleep 0:00 0.03% 0.40% postgres: freedomowner freedom ::1(44062) idle
7583 postgres 20 0 539M 7208K sleep 0:00 0.00% 0.00% postgres: postgres postgres [local] idle
13853 postgres 20 0 539M 5796K sleep 0:00 0.03% 0.00% postgres: freedomowner freedom ::1(44054) idle
13841 postgres 20 0 539M 5796K sleep 0:00 0.03% 0.00% postgres: freedomowner freedom ::1(44042) idle
13865 postgres 20 0 539M 4448K run 0:00 0.00% 0.00% postgres: postgres postgres [local] idleA votre avis, d'où peut venir cette surcharge inhabituelle ?
Quel test ou optimisation me conseillez-vous ?
Merci d'avance
Tony
Hors ligne
Je suis en particulier étonné du nombre important de requêtes en attentes comme le montre pg_top et du 56.2% de iowait :
Je suppose que vous voulez dire en attente du disque à cause de l'iowait.
A votre avis, d'où peut venir cette surcharge inhabituelle ?
Difficile à dire sans plus d'informations. Exécutez-vous des VACUUM de temps en temps ? l'autovacuum est-il activé ? Les disques sont-ils sur le serveur ? etc.
Guillaume.
Hors ligne
Je suis en particulier étonné du nombre important de requêtes en attentes comme le montre pg_top et du 56.2% de iowait :
Je suppose que vous voulez dire en attente du disque à cause de l'iowait.
.
Oui
A votre avis, d'où peut venir cette surcharge inhabituelle ?
Difficile à dire sans plus d'informations. Exécutez-vous des VACUUM de temps en temps ? l'autovacuum est-il activé ?
Le processus autovacuum est bien lancé :
postgres 27212 0.0 0.5 548876 11460 ? S 06:54 0:07 /usr/lib/postgresql/8.4/bin/postgres -D /var/lib/postgresql/8.4/main -c config_file=/etc/postgresql/8.4/main/postgresql.conf
postgres 27214 0.0 25.5 549236 525560 ? Ss 06:54 0:11 \_ postgres: writer process
postgres 27215 0.0 0.0 549136 892 ? Ss 06:54 0:02 \_ postgres: wal writer process
postgres 27216 0.0 0.0 549928 1580 ? Ss 06:54 0:01 \_ postgres: autovacuum launcher processExiste-il une commande pour connaitre l'heure de la dernière exécution du Vacuum ?
Les disques sont-ils sur le serveur ? etc.
C'est un serveur dédié avec des disques dédiés
Tony
Hors ligne
Existe-il une commande pour connaitre l'heure de la dernière exécution du Vacuum ?
Tout se trouve dans le catalogue statistique pg_stat_user_tables.
Concernant l'iowait, le problème est plutôt au niveau disque ou système de fichiers, pas au niveau PostgreSQL.
Guillaume.
Hors ligne
Existe-il une commande pour connaitre l'heure de la dernière exécution du Vacuum ?
Tout se trouve dans le catalogue statistique pg_stat_user_tables..
Cette table est vide. Je pense qu'il faut activer les statistiques pour l'alimenter ce qui n'est pas le cas à priori
Concernant l'iowait, le problème est plutôt au niveau disque ou système de fichiers, pas au niveau PostgreSQL.
J'ai tout de même l'impression que les premières requêtes utilisent beaucoup de mémoire et qu'il n'en reste plus suffisamment pour les suivantes ce qui entrainerait cette mise en attente
Le problème ne peut-il pas venir d'un mauvais paramétrage de la mémoire de Postgresql (shared_buffers, work_mem, maintenance_work_mem, effective_cache_size,..) ?
Sinon d'après vous, le problème viendrait du disque dur qui serait fatigué et fonctionnerait moins rapidement qu'auparavant ?
-> Est-il possible de faire un test à ce niveau ?
Merci d'avance
Hors ligne
Cette table est vide. Je pense qu'il faut activer les statistiques pour l'alimenter ce qui n'est pas le cas à priori
Du coup, l'autovacuum ne peut pas exécuter de VACUUM et d'ANALYZE vu qu'il ne peut pas détecter si les tables en ont besoin ou pas.
J'ai tout de même l'impression que les premières requêtes utilisent beaucoup de mémoire et qu'il n'en reste plus suffisamment pour les suivantes ce qui entrainerait cette mise en attente
Un shared_buffers trop petit peut ralentir les autres requêtes.
Le problème ne peut-il pas venir d'un mauvais paramétrage de la mémoire de Postgresql (shared_buffers, work_mem, maintenance_work_mem, effective_cache_size,..) ?
Je n'y crois pas. Une trop forte valeur de work_mem et maintenance_work_mem peut générer de grosses écritures. effective_cache_size ne peut avoir aucune incidence. shared_buffers peut, s'il est trop petit, être la cause de lectures supplémentaires.
Sinon d'après vous, le problème viendrait du disque dur qui serait fatigué et fonctionnerait moins rapidement qu'auparavant ?
-> Est-il possible de faire un test à ce niveau ?
Ça peut être une cause. L'autre possibilité est que les tables soient fragmentées dû fait du manque d'exécution des VACUUM. Une table fragmentée demandera plus de lectures de blocs, et généralement plus de déplacement de la tête de lecture.
Bref, pour moi, je penche plus vers une fragmentation importantes des tables et des index. Utilisez-vous VACUUM en dehors de l'autovacuum ? et REINDEX ?
Guillaume.
Hors ligne
Cette table est vide. Je pense qu'il faut activer les statistiques pour l'alimenter ce qui n'est pas le cas à priori
Du coup, l'autovacuum ne peut pas exécuter de VACUUM et d'ANALYZE vu qu'il ne peut pas détecter si les tables en ont besoin ou pas.
En fait, j'ai fais la requête sur la base 'postgres' et non pas sur la base de Dynacase.
Sur la bonne base, la table est bien remplie. Voici un extrait pour information :
relname | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
---------------------+--------------------------------+---------------------------------+--------------------------------+---------------------------------
doc31 | 01/02/2012 05:57:01.231986 CET | | 01/02/2012 05:57:01.242728 CET |
docvaultindex | 01/02/2012 06:00:49.701209 CET | 17/05/2011 18:40:58.591079 CEST | 01/02/2012 06:00:49.784525 CET | 17/05/2011 18:40:58.591079 CEST
usertoken | 01/02/2012 06:01:02.720471 CET | 28/04/2011 11:01:39.176441 CEST | 01/02/2012 06:01:02.735843 CET | 04/01/2012 16:53:13.462413 CET
doc7994 | 01/02/2012 05:56:55.275817 CET | | 01/02/2012 05:56:55.277852 CET |
doc20 | 01/02/2012 05:58:49.394601 CET | | 01/02/2012 05:58:49.404725 CET |
doc244220 | 01/02/2012 05:57:00.828779 CET | 08/11/2011 14:06:02.509226 CET | 01/02/2012 05:57:00.888176 CET | 08/11/2011 14:04:02.63594 CET
doc10631 | 01/02/2012 06:10:34.155425 CET | 01/02/2012 05:39:30.215997 CET | 01/02/2012 06:10:34.184137 CET | 01/02/2012 14:02:33.930995 CET
doc39 | 01/02/2012 05:56:59.36014 CET | | 01/02/2012 05:56:59.362097 CET |J'ai tout de même l'impression que les premières requêtes utilisent beaucoup de mémoire et qu'il n'en reste plus suffisamment pour les suivantes ce qui entrainerait cette mise en attente
Un shared_buffers trop petit peut ralentir les autres requêtes.
Le problème ne peut-il pas venir d'un mauvais paramétrage de la mémoire de Postgresql (shared_buffers, work_mem, maintenance_work_mem, effective_cache_size,..) ?
Je n'y crois pas. Une trop forte valeur de work_mem et maintenance_work_mem peut générer de grosses écritures. effective_cache_size ne peut avoir aucune incidence. shared_buffers peut, s'il est trop petit, être la cause de lectures supplémentaires.
Si vous voulez vérifier que rien ne vous parait bizarre dans mon paramétrage, voici mes valeurs :
Mémoire vive : 2 Go
max_connections = 64
shared_buffers = 512MB
work_mem = 8MB
maintenance_work_mem = 128MBMerci d'avance pour vos lumières
Hors ligne
Ce paramétrage semble cohérent. Tout dépend ensuite s'il s'agit d'un serveur dédié à PostgreSQL ou non, mais à priori ça me semble bon.
Il faudrait peut-être réindexer la base. Attention que cela prendre du temps et que cela bloquera les écritures sur les tables.
La dernière hypothèse est évidemment un problème disque.
Guillaume.
Hors ligne
Ce paramétrage semble cohérent. Tout dépend ensuite s'il s'agit d'un serveur dédié à PostgreSQL ou non, mais à priori ça me semble bon.
.
C'est un serveur dédié à l'application Web Dynanase. Donc c'est essentiellement les services de Postgresql et d'Apache qui tournent
Il faudrait peut-être réindexer la base. Attention que cela prendre du temps et que cela bloquera les écritures sur les tables.
Cela ce fait comment ?
La dernière hypothèse est évidemment un problème disque.
Si je ne trouve rien de plus, je creuserai effectivement cette piste. Cela expliquerait que la lenteur soit apparue quasiment du jour au lendemain sans rien faire de spéciale dans Postgresql
En tout cas, merci pour toutes les réponses
Hors ligne
Cela se fait comment ?
Il faut utiliser l'ordre SQL REINDEX (http://docs.postgresql.fr/9.1/sql-reindex.html) sans arguments. Il est aussi possible de passer par l'outil reindexdb (http://docs.postgresql.fr/9.1/app-reindexdb.html). Ça rend plus simple son automatisation.
Guillaume.
Hors ligne
pour réindexer la database entièrement c'est ça : REINDEX DATABASE nom_de_la_database;
on peut juste faire l'index ou la table
edit : grilled fffuuuu
Dernière modification par kenrio (01/02/2012 18:31:20)
Hors ligne
Pages : 1