cpu à 100% avec 1.5% de ram utilisé, comment optimiser la config ?

**clavier12AZQSWX** · 13/07/2011, 09h19

Bonjour,

Je reprends la maintenance d'un serveur où il y a postgresql 8.1, debian etch et un erp installé dessus : je ne peux pas faire de mise à jour à cause de l'applicatif en prod.

Voilà, le problème est qu'une certaine opération dans l'ERP cause une lenteur incroyable pendant 20s, mettant le cpu à 100% et la ram avec seulement 1.5% d'utilisée. J'ai obtenu ces valeurs en faisant un top pendant le traitement.

Y a-t-il moyen de modifier un paramètre dans la config permettant à plus de ram d'être utilisée pour optimiser la vitesse. Je ne sais pas comment obtenir les infos matériel du serveur. On m'a globalement dit qu'il devait être robuste mais peut-être mal configuré..

Y a-t-il un moyen de savoir exactement quelles requêtes SQL sont exécutées pendant cette lenteur ?

Je me demande aussi si ce n'est pas le disque dur qui fait trop de chose au lieu d'utiliser la RAM, mais comment le savoir ?

Merci à vous et de votre aide (ou de me mettre sur une piste flagrante)

Merci de votre aide.

**estofilo** · 13/07/2011, 11h39

Pour savoir quelle est la requête exécutée, regarder la table pg_stat_activity.
Pour savoir si le disque dur travaille, utiliser la commande shell vmstat (colonnes bi et bo) ou iostat

**clavier12AZQSWX** · 15/07/2011, 11h32

où est la table pg_stat_activity ? je ne la vois pas.

j'ai fait un vmstat.

pendant que ça rame à fond (cpu 100%) il ya cela :

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0 302236  19592 111092 1262188    0    0     1     1    0    1  1  0 98  0

et quand c'est terminé et revenu à la normal il ya cela :

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0 302236 112932 106140 1248704    0    0     1     1    0    1  1  0 98  0

**estofilo** · 15/07/2011, 11h40

pg_stat_activity est une vue du schéma pg_catalog.
Dans la sortie vmstat montrée, le CPU ne travaille pas (colonne id=idle à 98%)

Il faudrait laisser tourner vmstat 1 pendant plusieurs secondes pour avoir des résultats plus probants.

**clavier12AZQSWX** · 15/07/2011, 11h59

faut-il faire un "vmstat 1" en root ou en compte utilisateur (celui de l'erp) ou en compte postgres ?

**estofilo** · 15/07/2011, 12h02

Pour vmstat, peu importe, le résultat sera le même quel que soit l'utilisateur qui le lance.

**clavier12AZQSWX** · 15/07/2011, 12h03

voilà la phase allant du 0% au 100% en revenant au 0% :

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 302236 117464 87308 1247204 0 0 1 1 1 1 1 0 98 0
0 0 302236 117432 87308 1247100 0 0 0 0 634 971 1 0 98 0
1 0 302236 41648 87324 1247100 0 0 0 56 736 892 14 5 81 0
1 0 302236 41648 87324 1247100 0 0 0 0 572 639 25 0 75 0
1 0 302236 41640 87324 1247100 0 0 0 0 400 577 26 0 74 0
1 0 302236 41640 87324 1247104 0 0 0 252 304 284 25 0 75 0
1 0 302236 41632 87324 1247104 0 0 0 0 283 291 25 0 75 0
2 0 302236 41588 87324 1247104 0 0 0 0 278 258 25 0 75 0
1 0 302236 41588 87332 1247096 0 0 0 32 258 246 25 0 75 0
1 0 302236 41588 87332 1247104 0 0 0 0 275 258 25 0 75 0
1 0 302236 41588 87332 1247104 0 0 0 236 250 253 25 0 75 0
1 0 302236 41668 87332 1247104 0 0 0 0 264 253 25 0 75 0
1 0 302236 41668 87332 1247104 0 0 0 0 240 246 25 0 75 0
1 0 302236 41692 87332 1247104 0 0 0 0 291 247 25 0 75 0
1 0 302236 41692 87332 1247104 0 0 0 0 244 242 25 0 75 0
1 0 302236 41812 87336 1247104 0 0 0 4 287 269 25 0 75 0
1 0 302236 41812 87336 1247104 0 0 0 0 244 250 25 0 75 0
1 0 302236 116944 87336 1247324 0 0 0 0 3141 5810 17 3 80 0
1 0 302236 116780 87336 1247284 0 0 0 0 2140 3813 22 0 78 0
0 0 302236 116904 87336 1247212 0 0 0 0 246 291 1 0 99 0
0 0 302236 116904 87336 1247212 0 0 0 324 200 271 0 0 100 0

**clavier12AZQSWX** · 15/07/2011, 12h21

pour info le serveur est un bi-cou xeon 5130, soit 4 cores à 2Ghz au total (mais bon postgres81 n'utilise pas le smp)
et il ya 2Ghz de RAM physique

**estofilo** · 15/07/2011, 12h36

Les colonnes bi et bo indiquent l'activité disque, et il n'y en a quasiment pas.
La colonne us indique que le cpu est à 25% occupé, c'est certainement un 4-coeurs dont 1 coeur à 100% sur la requête.
Dans la colonne "free" on voit que la mémoire passe de 117432 à 41648, soit environ 70Mo alloués par l'opération, puis ça revient à 116944
Les colonnes si et so indiquent l'activité swap et il n'y en a aucune.
les colonnes cache et buff donnent le cache disque et il est bien rempli à 1,2 Go

Tout ça parait très normal et il n'y a rien qui indiquerait des réglages à changer.

**SQLpro** · 15/07/2011, 14h16

Des réglages non, mais peut être des pratiques !
Par exemple voir s'il n'y a pas un usage abusif (et dans l'ordre ) :

des curseurs
des déclencheurs
des fonctions

notamment avec beaucoup de code itératif plutôt qu'à l'aide de requêtes ensemblistes !

A +

**papao** · 17/11/2011, 13h03

Bonjour les amis,

je tiens à vous dire au début que je suis un nouveau dans le métier

mon problème à moi c'est dans l'inverse, consommation de mémoire virtuel 100% et consommation CPU 5%

le serveur :
- windows serveur 2008 professionnel
- 2500 Mo de ram
- CPU 2.27 Ghz
C'est une machine virtuel

J'utilise postgres 9.0. Je vous remercie déjà

**SQLpro** · 17/11/2011, 13h09

Ça c'est parfaitement normal !

A +

**papao** · 18/11/2011, 09h08

pourquoi tu dis que c'est parfaitement normal?

**SQLpro** · 18/11/2011, 14h47

Un SGBDR fonctionne quasi exclusivement en RAM, le disque n'étant qu'un épiphénomène dû au fait que les mémoires actuelles sont volatiles.
Il consommera donc toute la RAM si besoin est sans la restituer.

A +

**papao** · 19/11/2011, 07h53

et si t'ajoute ta ram, ça changerais quelque chose?

je voudrais dire, il reconsomme la mémoire que t'as? et ça évoluerais la performence de ta base?

**SQLpro** · 21/11/2011, 10h41

Si vous ajoutez de la RAM il est probable qu'elle soit consommée rapidement par le SGBDR, en particulier si la base de données est plus grande que la RAM.

Mais cela dépend aussi de vos réglages et notamment du paramétrage des shared_buffer (cache des données) qui en principe devrait être de 60 à 90 % de la RAM, suivant la quantité de RAM.

A +

**papao** · 22/11/2011, 07h07

effectivement, comme ma base est sur une machine virtuel, j'ai augmenter ma ram mais peut de temps après, le SGBD l'a encore consommé à 100%.

dit, comment ont fait le calcul par rapport au shared_buffer qui est à 32MB par défaut? combien de Go de ram a besoin un SGBD par défaut?

Je te remercie