vmstat pour déterminer la mémoire dont oracle a besoin.

[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.

[LeoAnderson]

Un bon moyen pour réduire la charge, notamment mémoire peut être de mettre en place MTS.

[genio]

Merci Léo mais pour le MTS, cela n'en vaut vraiment pas la peine car il n'y a pas assez d'utilisateurs...
Néanmoins, si cela ne vous prends pas trop de temps, pouvez-vous répondre à mes questions 2°) et 3°)...
Et puis aussi, quand ma PGA_AGGREGATE_TARGET est à zéro, la PGA prise par les utilisateurs est-elle limitée ?

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

[LeoAnderson]

Si java n'est pas utilisé, ça sert à rien d'avoir une JAVA POOL car oui, ça consomme des ressources pour les autres zones mémoires

Avant de réduire la SGA, faudrait au minimum connaitre les ratio des bases afin de voir quelle zone pourrait être baissée (shared ou buffer typiquement?)


Pour le sens de PGA_AGGREGATE_TARGET, je t'invite à lire la doc !
http://download-uk.oracle.com/docs/c....htm#sthref666

Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL workareas are sized using the *_AREA_SIZE parameters.


Pour conclure : si tu ne peux pas mutualiser la mémoire par MTS et si tu ne peux pas baisser les SGA, tu dois rajouter de la RAM.

[pifor]

Envoyé par genio

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).

Envoyé par genio

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.

[genio]

merci pour vos réponses éclairées...
Une petite dernière... j'ai vu sur une de nos instances la chose suivante :

SGA-MAX_SIZE = 598 707 040 et
PGA_AGGREGATE_TARGET = 1 073 741 824 !

La PGA-AGGREGATE est 3 fois plus grande que la SGA_MAX_SIZE...
Comment est-ce possible ?

Merci encore pour vos disponibilités...

[genio]

Et puis une autre aussi ..
Quand Léo me dit :

Avant de réduire la SGA, faudrait au minimum connaitre les ratio des bases afin de voir quelle zone pourrait être baissée (shared ou buffer typiquement?)

Voici les tailles mémoires de mon instance
SGA_MAX_SIZE ==================> 400 M SHARED_POOL_RESERVED_SIZE ========> 9 M
SHARED_POOL_SIZE=================> 180 M
JAVA_POOL_SIZE===================> 180 M
PGA_AGGREGATE_TARGET=============> 0
SORT_AREA_SZE====================> 0,6 M
HASH_AREA_SIZE====================> 1M
DB_BLOCK_BUFFER===================> 0,2 M
DB_CACHE_SIZE = 0

Etant donné que l'application ne fait pas de Java, je vais reduire la JAVA_POOL_SIZE à 0 =>
Mais, au lieu de réduire la SGA, j'aurais tendance à la garder telle quelle mais à :
- doubler la SHARED_POOL de 180 M (la place prise par la JAVA_POOL)
- à doubler la SHARED_POOL_RESERVED_SIZE...
- à doubler/tripler la SORT-AREA_SIZE
1°) Mon raisonnement est-il correct ?
2°) Si oui, les perf seront elles meilleurs
3°) Si non, pourquoi ?

Merci encore ...

[genio]

Pas de réponse à mon dernier post ?

[pifor]

Envoyé par genio

merci pour vos réponses éclairées...
Une petite dernière... j'ai vu sur une de nos instances la chose suivante :


La PGA-AGGREGATE est 3 fois plus grande que la SGA_MAX_SIZE...
Comment est-ce possible ?

Merci encore pour vos disponibilités...

Il n'y a pas forcément de lien entre les 2: la SGA et la PGA sont 2 ressources différentes La taille de la PGA peut être plus importante que la taille de la SGA pour différentes raisons. Il faut au moins être sûr que l'on a la mémoire physique correspondante.

Envoyé par genio

- à doubler/tripler la SORT-AREA_SIZE
...

Ca ne sert à rien si PGA_AGGREGAGE_TARGET est positionné.

Pour les autres questions, on ne peut pas a priori dire quel est l'effet de changer des paramètres pour la SGA. Le mieux est encore de le tester et de comparer les performances.

[genio]

J'espère que vous avez passé un bon week ...

Pifor, quand vous dites :

Il n'y a pas forcément de lien entre les 2: la SGA et la PGA sont 2 ressources différentes La taille de la PGA peut être plus importante que la taille de la SGA pour différentes raisons. Il faut au moins être sûr que l'on a la mémoire physique correspondante.

1°) Je l'entends bien mais dans mon cas ou la place mémoire de ma machine unix est très petite, comment Oracle va-t-il reserver ma PGA ? Imaginons qu'il me reste 100 méga de mémoire sur mon serveur (après allocation de la SGA) et que la PGA_AGGREGATE_TARGET demande 300 Mégas, y-aura-t-il un swap sur disque à chaque connexion d'un utilisateur ?
2°) La place mémoire prise par la PGA_AGGREGATE-TARGET est-elle réservée à l'ouverture d'Oracle ?


Quand vous dites :

Il n'y a pas forcément de lien entre les 2: la SGA et la PGA sont 2 ressources différentes La taille de la PGA peut être plus importante que la taille de la SGA pour différentes raisons.

Pouvez-vous me citer une raison ?

Merci encore pour vos disponibilités et vos réponses...

[pifor]

Envoyé par genio

J'espère que vous avez passé un bon week ...

Pifor, quand vous dites :


1°) Je l'entends bien mais dans mon cas ou la place mémoire de ma machine unix est très petite, comment Oracle va-t-il reserver ma PGA ? Imaginons qu'il me reste 100 méga de mémoire sur mon serveur (après allocation de la SGA) et que la PGA_AGGREGATE_TARGET demande 300 Mégas, y-aura-t-il un swap sur disque à chaque connexion d'un utilisateur ?
2°) La place mémoire prise par la PGA_AGGREGATE-TARGET est-elle réservée à l'ouverture d'Oracle ?

D'après la discussion AskTom http://asktom.oracle.com/pls/ask/f?p...:8759826405304 (voir la question du 29 juin 2004 qui compare les affirmations d'un formateur Oracle University et les réponses de Tom Kyte), la mémoire définie par PGA_AGGREGATE_TARGET n'est pas allouée en 1 seule fois avec Oracle 9i mais en fonction des besoins des sessions. Il s'agit aussi d'une ressource commune à toutes les sessions et non à une seule. Si au bout d'un certain temps, les 300 Mo DE PGA sont atteints ou dépassés, alors s'il ne restait que 100 Mo de RAM libre, alors oui il doit y a voir swapping. Si les besoins en PGA décroissent, la mémoire peut être libérée. L'évolution de la PGA peut-être consultée avec la vue V$PGASTAT.

Quand vous dites :

Envoyé par genio

Pouvez-vous me citer une raison ?
...

Imaginons une base avec un millier de connexions concurrentes, une application avec quelques dizaines de requêtes SQL écrites avec une utilisation intensive de PL/SQL (packages, variables locales), quelques Go de données: la SGA peut faire quelque centaines de Mo mais la PGA peut dépasser la SGA si on admet que chaque session a besoin de 2 Mo de PGA. Autre exemple, si on veut essayer d'éviter de faire des tris sur disque, on peut décider d'avoir une PGA plus grande que la SGA.