Discussion :

[genio]

Bonjour les forumnautes...
quand je saisie vmstat sur mons erveur UNIX Solaris.. j'ai la réponse suivante...

root@toto# vmstat
root@uorap03 # vmstat
kthr-----memory---------------page---------------------------disk----------faults-----------cpu
r b w-----swap free re mf------pi po fr de sr-----------------2m 2m 2m m0----in sy------cs us sy id
0 0 0 3036208 119632 45 76 ---199 14 15 0 36---------------13 12 12 1------319 384 --- 419 2 1 97

N'étant pas un gros spécialiste UNIX, pouvez-vous me dire quelle est la taille de la mémoire de mon serveur... et même ce que veulent dire les zones swap , free, pi, po etc...

Merci d'avance pour vos réponses...

En fait, j'ai un problème de performance sur un serveur qui contient 7 instances... quand les utilisateurs saississent les données de début de mois, les réponses rament grave... j'ai effectué des explain sur les ordres et ils ne sont pas en cause... j'ai regardé les sga et je voudrais les comparer maintenant avec la taille mémoire du serveur...

[pifor]

Je ne sais pas si vmstat donne la taille mémoire de la machine. Une technique qui marche souvent consiste à consulter le syslog de la machine (/var/adm/messages sur Solaris) et de rechercher les lignes qui affichent la taille de la RAM de la machine au boot:

<date> <hostname> unix: [ID 389951 kern.info] mem = 8388608K (0x200000000)
<date> <hostname> unix: [ID 930857 kern.info] avail mem = 8221523968

D'après la man page, la donnée free de vmstat dit qu'il reste 119632 K de libre sur le système.

Avez-vous tracé une connection client et utiliser tkprof pour avoir une trace complète d'une session base de données ? Il peut être intéressant aussi d'utiliser Statspack avec un intervalle de snapshot de quelques minutes qui donne beaucoup d'informations sur la fonctionnement de l'instance y compris les grosses requêtes. Statspack est particulièrement intéressant pour comparer un état normal de la base avec une état ralenti de la base.

[genio]

Merci pour ta réponse...

Je pense effectivement que mon serveur est bien petit par rapport aux instances présentes... j'ai fait un diagnostic :
J'ai un serveur de 4 Gigas de RAM => Ok
J'ai 8 instances dont les SGA font 400 mégas chacunes...
La PGA de chaque instance fait 11 Méga
Un rapide calcul nous donne la taille mémoire prise par les 8 instances : (8 x 400 M) + (8 x 11 M) = 3200 M + 88 M = 3288 Mégas = 3,2 Gigas
Les problèmes de perf apparaissent quand, 1 fois par mois, tous les utilisateurs effectuent, en même temps, leurs manip de recyclage des données...
1°) Ais-je raison de dire que la place mémoire restante du serveur, est trop petite (4 Gigas - 3,2 Gigas = 800 Mégas !) ?
2°) Et si oui, comment faire, sans changer de serveur, pour améliorer tout ça ...
3°) Dois-je réduite la sga ?
4°) J'ai vu que les Java_POOL_SIZE étaient paramétrées à la même taille que les SHARED_POOL_SIZE (environ 2 Gigas)... Si je réduit la JAVA_POOL_SIZE à 500 Méga et que j'accentue la JAVA_POOL_SIZE à 3.5 Gigas, les performances seront-elles meilleures ...

Merci pour vos réponses...

[pifor]

Comment calculez-vous la PGA ? Même avec PGA_AGGREGATE_TARGET la PGA est allouée dynamiquement et peut varier.

S'il reste vraiment 800 Mo de libre:
1. il faudrait essayer de faire le lien avec les 119 Mo de libre donnés par vmstat
2. le problème de performance ne vient sans doute pas de là.

Pour réduire la SGA ou les Java Pool Size, c'est quelque chose qu'il faudrait tester dans un certain nombre de cas représentatifs: on ne peut pas vraiment prévoir dans quel sens cela va jouer à priori.
Est-ce que l'application utilise Java dans la base de données ?

Si le problème de performance est lié à un traitement donné, il faudrait plutôt mettre la trace SQL et utiliser tkprof pour avoir une idée plus précise de ce qui se passe au moins dans une session de la base à ce moment là.

[genio]

La PGA je l'ai trouvé avec l'ordre : SELECT * FROM v$pgastat WHERE name LIKE '%total%';

total PGA inuse ==============================> 8080384 bytes
total PGA allocated ===========================> 11568128 bytes
total freeable PGA memory =====================> 0 bytes
total PGA used for auto workareas ================> 0 bytes
total PGA used for manual workareas ==============> 0 bytes[/QUOTE]

Mon paramètre PGA_AGGREGATE_TARGET est à 0...

Le poblème c'est que mon TKPROF va me renseigner sur 1 une seule instance, or là, 8 instances, en même temps, effectuent des mises à jours sur un même serveur...
1°) Le TKPROF va-t-il me dire où ça coince si j'installe une trace sur 1 des 8 instances ? D'autant plus que ces bases là étant très petites, les ordre consommateurs passent très bien en periode 'normale' et les explains sont bons...

2°) Si l'application client-serveur n'utilise pas JAVA, la zone JAVA_POOL_SIZE sera-t-elle utilisée ? Si elle ne l'est pas, prends-elle de la place mémoire que l'on, pourrait rétrocéder à la SHARED ?

3°) J'ai du mal à comprendre pourquoi ma JAVA est égale à ma SHARED... Comment Oracle se débrouille-t-il pour 'switcher' entre les deux... sont-ce deux 'zones' différentes de la SGA, ou bien suivant le déroulement des actions, l'une prend la main sur l'autre ?

Merci pour vos réponses ...

[LeoAnderson]

Attention : Solaris met en cache les IO, et donc, utilise de la RAM
d'où la différence entre le vmstat et le calcul.

Avoir ce cache kernel permet de transformer des "physicals I/O" d'un point de vue oracle en "Cache I/O".

100 Mo de free, c'est clairement pas assez.
quand ces 100 Mo sont utilisés, les I/O se font alors réellement physiquement et là, ça va ramer.

[pifor]

1°) Le TKPROF va-t-il me dire où ça coince si j'installe une trace sur 1 des 8 instances ? D'autant plus que ces bases là étant très petites, les ordre consommateurs passent très bien en periode 'normale' et les explains sont bons...
...

TKPROF pour une session donnée permet d'analyser ce qui s'est passé dans une session à un moment donné mais ne permet pas de savoir ce qui se passe dans les autres sessions si on ne les trace pas ou de donner des statistiques au niveau de l'instance: pour avoir des statistiques au niveau de l'instance il faut Statspack ou utiliser OEM ou utiliser certains vues V$ en faisant soi-même les snapshots. TKPROF est plus complet que l'EXPLAIN PLAN car il donne en plus les conditions exactes dans lesquelles les requêtes ont été exécutées (accès caches, I/O, et les waits).

3°) J'ai du mal à comprendre pourquoi ma JAVA est égale à ma SHARED... Comment Oracle se débrouille-t-il pour 'switcher' entre les deux... sont-ce deux 'zones' différentes de la SGA, ou bien suivant le déroulement des actions, l'une prend la main sur l'autre ?
..

LA SGA est composée en même temps du shared pool, du java pool si configuré, du buffer cache et d'autres composants. Je ne crois pas que l'instance peut "switcher" entre le shared pool et le java pool. Comme on vous l'avez déjà dit, si vous être sûr de ne pas utiliser les fonctionnalités Java, désactivez le java pool avec java_pool_size = 0.