Discussion :

[joziel]

Bonjour,
Je suis sous Oracle 9i / RHEL 4 et j'ai rencontré aujourd'hui un leger soucis...
Sur la base en question, il etait impossible d'établir de nouvelles connexions en mode "SHARED".
Je me dis que les utilisateurs deja connectés peuvent continuer à travailler, seulement ce n'est pas le cas, on me remonte de grosses lenteurs, voire un 'freeze' de l'application.
Je regarde le fichier alert.log, aucun message d'erreur, pas de rotation de redo toutes les minutes (le dernier remonte a 2h), au niveau du systeme je n'ai pas non plus d'iowait impressionnant...

le nom de dispatchers = 48, le nombre de sessions=2048 ...
J'ai constaté qu'il n'y avait que 496 utilisateurs connectés

Je ne sais pas trop où regarder pour voir si une limite est atteinte...
Merci pour vos réponses

[Mathias44]

Bonjour,

Une machine qui swappe ? Un FS full genre / ?

Que donne un vmstat 3 5 ? Un df -k ?
As tu des erreurs dans /var/log/messages ?

[joziel]

Bonjour,
voici le résultat pour df :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda9             2.0G  668M  1.3G  35% /
/dev/sda3              99M   27M   68M  29% /boot
none                  5.8G     0  5.8G   0% /dev/shm
/dev/sda12            494M   25M  444M   6% /tmp
/dev/sda5              12G  5.9G  4.7G  56% /usr
/dev/sda11            1.5G  363M 1001M  27% /var
/dev/sda2             6.2G  5.6G  384M  94% /home
/dev/sdb5             3.6G   33M  3.6G   1% /oradata/trace
/dev/sdb6              22G   15G  7.0G  68% /oradata/temp
/dev/emcpowerf1       150G   50G  101G  33% /oradata/backups
/dev/emcpowerc         50G   30G   21G  60% /oradata/data
/dev/emcpowera         32G   11G   22G  34% /oradata/indexes
/dev/emcpowerb        2.0G  1.3G  698M  66% /oradata/redolog
/dev/emcpowerd        200G   25G  176G  13% /oradata/arch
/dev/emcpowerg1       128G   25G  104G  19% /oradata/blobs/indexes/ip1
/dev/emcpowerh1       200G   26G  175G  13% /oradata/blobs/data/dp1

et pour vmstat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
vmstat 3 5
procs                      memory      swap          io     system         cpu
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0      0  30888 300168 10879656    0    0     0     0    0     0  0  0  1  0
 0  0      0  31560 300172 10879672    0    0     5   251  434   979  3  1 95  1
 0  0      0  31136 300184 10879704    0    0    11   104  338   872  4  0 95  1
 3  0      0  24000 300184 10879744    0    0     9   815  717  1643 13  5 80  3
 0  0      0  23216 300192 10876188    0    0    28   235  721  1850 22  2 74  2

Enfin, en ce qui concerne la swap, voici l'état de la mémoire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Mem:  12130936k av, 12103460k used,   27476k free,       0k shrd,  300292k buff
                   9125120k actv, 2327616k in_d,   58660k in_c
Swap: 8289372k av,       0k used, 8289372k free                 10875848k cached

[Mathias44]

Ton pb est permanent, ponctuel, régulier, n'est arrivé qu'une fois ?
Pas d'erreurs OS dans /var/log/messages ?
Pas de pb réseau (encore le réseau qui merde ! )
Quel type d'appli ? Le pb de perfs n'a pas pu avoir lieu en amont ?

[joziel]

mon probleme est ponctuel, mais ponctuel 2 fois déja en 1 semaine...
Je n'ai pas d'erreur dans /var/log/messages, pas de soucis réseau (c'est monitoré)
L'appli concernée est une application pour des commerciaux...
Je ne pense pas que le problème ait pu avoir lieu en amont parce que ça s'est produit chez tout le monde. Le point central, c'est le serveur Oracle malheureusement...
J'ai fait du ménage dans les sessions utilisateurs (et depuis ca va mieux), donc je me dis que j'avais peut-etre atteint le nombre max, mais d'un autre coté, le problème n'aurait du etre que pour les utilisateurs qui n'étaient pas encore connectés... Etrange...

[fatsora]

Bonjour ,

Il faut voir les contentions propres au shared


voici des docs sur le shared

http://www.stanford.edu/dept/itss/do...2/build_db.htm

notamment la section

Identifying Contention for Shared Servers


et celui-ci en francais

http://www.wikiora.com/index.php?opt...re-7&Itemid=59