Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Général » Calcul avec des sum et des group by » 15/03/2012 14:03:59
Merci beaucoup.
Ça fonctionne maintenant avec COALESCE.
#2 Général » Calcul avec des sum et des group by » 15/03/2012 13:09:01
- Tony
- Réponses : 3
Bonjour,
Dans une table, j'ai des champs contenant des nombres ou des valeurs null
Cette requête me fait correctement la somme des champs
select client , sum(montant_vendu), sum(montant_facture)
from matable
group by clientMais si je veux calculer avec cette requête, la différence des deux montants, cela ne fonctionne que si les montants contiennent des valeurs :
select client , sum(montant_vendu), sum(montant_facture), sum(montant_vendu)-sum(montant_facture)
from matable
group by clientSi le champ 'sum(montant_facture)' est vide, le resultat sera vide alors qu'il devrait être égale à sum(montant_vendu)
Je pense que c'est un problème de conversion de valeurs null en nombre, mais je n'y arrive pas.
Merci d'avance pour votre aide
#3 Re : Général » ORDER BY sur un champ de type text contenant uniquement des nombres » 14/02/2012 11:53:30
Bonjour.
Vous pouvez utiliser dans votre requête une clause ORDER BY nom_champ::integer pour cela.
Super.
Merci beaucoup pour la réponse rapide et efficace
#4 Général » ORDER BY sur un champ de type text contenant uniquement des nombres » 14/02/2012 11:42:41
- Tony
- Réponses : 3
Bonjour,
J'ai une table avec un champ de type 'text' mais ne contenant que des nombres
Est-il possible de faire un order by en précisant que l'on souhaite avoir un tri de type numérique pour éviter d'avoir cela comme résultat :
1
10
2
200
3Évidemment, j'aimerais autant ne pas devoir toucher à la structure de la table
Merci d'avance
#5 Re : Optimisation » Lenteur de Postgresql depuis queslques jours » 01/02/2012 18:18:31
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
#6 Re : Optimisation » Lenteur de Postgresql depuis queslques jours » 01/02/2012 17:16:51
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
#7 Re : Optimisation » Lenteur de Postgresql depuis queslques jours » 01/02/2012 11:54:06
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
#8 Re : Optimisation » Lenteur de Postgresql depuis queslques jours » 01/02/2012 11:30:42
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
#9 Optimisation » Lenteur de Postgresql depuis queslques jours » 01/02/2012 11:06:49
- Tony
- Réponses : 10
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
Pages : 1