[Rubriques Unix et Oracle] Tuning Oracle sous Linux (approche système)

Tuning Oracle sous Linux (approche système)

vendredi 10 octobre 2008
par Laurent
popularité : 26%

Dans cet article, je me propose d’expliquer comment détecter des problèmes de performances Oracle fonctionnant sous Linux.

Cette détection se base sur des outils système standard UNIX (vmstat, sar, etc.). L’analyse se positionne donc au niveau du système d’exploitation, et ne dispense pas d’une analyse au niveau base(s) de données (analyse des v$, contentions mémoire, latch etc.)

Quelques rappels

Lorsqu’un client vient nous voir avec le traditionnel "Ca rame ... tu ne pourrais pas regarder la base ???", il est primordial d’adopter une méthodologie, et en tuning, il n’y a pas de recette miracle mais des recettes qui sont propres à chacun d’entre nous. Je donnerai donc ici ma vision des choses, qui a des avantages, des inconvénients ; qui conviendra à certains et ne conviendra pas à d’autres !

Personnellement, j’attaque toujours le problème coté base et plus particulièrement coté applicatif ... donc SQL. Je réalise donc toujours une analyse des top-sql (buffer gets, taux de parse ...) en premier lieu. Puis, une analyse des top wait-events (avec Statspack, AWR).

En fonction de cela, j’irai regarder plus précisément en mémoire, les entrées/sorties disques. En parallèle de cela, je conserve un oeil sur l’état des CPUs et des indicateurs associés.

Les outils système

Lorsqu’on utilise des outils système, il va de soi qu’il faut savoir comment fonctionne son système : gestion de la swap, ordonnancement des processus sur les CPUs etc.

Le but de cet article n’est pas de faire le détail de fonctionnement de l’OS Linux. Pour le lire, sachez comment fonctionne cet OS !

Dernière remarque, sous Linux Redhat, les outils cités ci-dessous sont disponibles dans le paquet rpm sysstat qu’il faut donc installer.

Enfin, n’oubliez pas la commande "man" qui permet d’obtenir les pages de manuel de l’outil : Ex :



$ man iostat

SAR : System Activity Reporter

SAR Mesure un certain nombre de métriques système (mémoire, IO, échange disque, SWAP etc.)

Il permet de visionner ces métriques périodiquement et en temps réel

Syntaxe :



$ sar <option> <interval> <count>

avec "Interval" en secondes

Il permet également la collecte (toutes les 10minutes) et l’historisation de ces mêmes métriques pendant un mois Syntaxe :



$ sar <option> <interval> <count> -f /var/log/sa/saXX



<Interval> n’a pas d’influence ici car les collectes sont faites toutes les 10minutes 



Où XX représente le jour du mois (sa23 représente le 23ème jour du mois)

vmstat

Vmstat est l’outil permettant de surveiller la mémoire virtuelle, certains aspects des processus, le paging, et également l’activité CPU.

Syntaxe :



$ vmstat <interval> <count>



Interval est donné en secondes

Pour la signification des colonnes, cf. "man vmstat"

iostat

Iostat permet d’obtenir les informations de charge IO : activité disque, taille des files d’entrée/sortie, hotspots concernant les élements de stockage d’un système

Syntaxe :



$ iostat <options> <interval> <count>



Interval est donné en secondes

Pour les options et la signification des colonnes, cf. "man iostat"

mpstat

Mpstat permet d’obtenir des informations sur la charge des CPUs, ou des cores constituant un système.

Syntaxe :



$ mpstat [ -P ALL/ <cpu#> ] <interval> <count>



Interval est donné en secondes

Pour la signification des colonnes, cf. "man mpstat"

Autres Commandes

top

L’utilitaire "top" est un utilitaire temps réel permettant d’obtenir des informations rapidement sur des nombreux paramètres : load average, nombre de processus, mémoire physique, swap, etat des processus etc.

La commande top est également un outil interactif. On peut par exemple filtrer les processus par utilisateur, par groupe de processus etc.

Coté mémoire avec Oracle, attention à ne pas cumuler les valeurs SHR (Shared memory pour les process). En effet, cette colonne indique le volume de mémoire partagée attachée au processus. Or, dans une instance, les processus attachent tous les segments de mémoire partagée qui sont identiques ... car partagé ! Attention, aux cumuls dans top !

free

La commande free permet de donner l’état de la mémoire : totale, libre, partagée, swap et bufferisée.

Free permet d’obtenir le volume de mémoire allouée, mise en cache. Sous linux, la mémoire mise en cache est une mémoire allouée. Cette mémoire est utilisée par les processus en cours et une partie est laissée libre pour tout processus (nouveau ou déjà créé) en faisant la demande au système.

Prenons l’exemple de la sortie "free" suivante :



$free

             total       used       free     shared    buffers     cached

Mem:       8177320    3471324    4705996          0     484616    1806372

-/+ buffers/cache:    1180336    6996984

Swap:      6815728          0    6815728

La sortie montre :
8177320 Ko de mémoire physique soit 8Go de mémoire physique totale
3471324 Ko de mémoire physique utilisée et 4705996 Ko de mémoire physique libre
6815728 Ko de mémoire swap totale
0 Ko de swap utilisée et donc 6815728 Ko de swap libre

Parmi la mémoire mise en cache :
1180336 Ko sont actuellement utilisés par le système
1806372 Ko sont mis en cache, la marge de manoeuvre pour les processus en faisant la demande est de : 1806372 - 1180336 = 626036 Ko. Attention : le système peut cela dit mettre en cache beaucoup plus de volume si nécessaire !

pmap

L’utilitaire pmap permet d’afficher la cartographie d’un processus en terme d’utilisation de la mémoire. Il permet de voir, entre autre :
les segments de mémoire partagée attachés au processus
les segments de mémoire privés
les librairies et leur adressage mémoire utilisées par ce processus ...



Exemple de sortie pmap d'un processus serveur (shadow process)

$ ps -ef | grep LOCAL

oracle    6547     1  0 Oct08 ?        00:00:50 oracletest1 (LOCAL=NO)



$ pmap -x 6547

6547:   oracletest1(LOCAL=NO)

.../...

00d78000    460K r-x--  /HOME/oracle/product/10.2.0/db_1/lib/libocr10.so

00deb000      4K rwx--  /HOME/oracle/product/10.2.0/db_1/lib/libocr10.so

00dec000      4K rwx--    [ anon ]

00ded000   7052K r-x--  /HOME/oracle/product/10.2.0/db_1/lib/libjox10.so

014d0000    264K rwx--  /HOME/oracle/product/10.2.0/db_1/lib/libjox10.so

01512000      4K rwx--    [ anon ]

08048000  78524K r-x--  /HOME/oracle/product/10.2.0/db_1/bin/oracle

0ccf7000    332K rwx--  /HOME/oracle/product/10.2.0/db_1/bin/oracle     <-- mémoire pour 

                                                                        le processus système

0cd4a000    120K rwx--    [ anon ]

0d085000    404K rwx--    [ anon ]

20000000 266240K rwxs-    [ shmid=0x20002 ]                             <-- segment de mémoire 

                                                                            partagée attachée 

                                                                            à ce processus

.../...

bfe16000    136K rwx--    [ stack ]

Analyse d’une contention CPU

Avant de commencer, il est bon de savoir identifier une machine qui est dite "CPU-bound".

Cette info se détermine grace au facteur de charge (load factor). Ce facteur de charge est dépendant de ce qu’on appelle la charge moyenne ou "load average".

Cette charge moyenne peut-être obtenue avec les outils top, uptime.

Ex :



uptime

 11:09:53 up 2 days,  9:47,  1 user,  load average: 6.10, 6.83, 6.85

La charge est donnée (dans l’ordre) pour : la dernière minute, les 5 dernières minutes, et les 15 dernières minutes.

Ce load average n’a pas d’unité, en revanche, si il est rapporté au nombre de CPU, on obtient alors le facteur de charge (load factor) qui permet de savoir si la machine est chargée ou non.

load factor = load average / nombre de CPU

Si ce facteur est :
inférieur à 1 : les CPU de la machine sont sous-utilisés
entre 1 et 2 : les CPU sont utilisés à une charge correcte
supérieur à 2 : les CPU sont surchargés. On dit que la machine est CPU-bound.

Le tableau ci-dessous permet d’identifier les problèmes de CPU et d’orienter ses choix dans le but de tuner la machine.

Symptôme	Détection	Paramètre déterminant	Mesures curatives
N/A	load factor = load avegage / #CPU	LF < 1 : CPU sous utilisés 1 LF > 2 : CPU surchargés	Investiguer en profondeur d’autres points
Temps idle important et problèmes de performances	vmstat mpstat -P ALL sar -u iostat -c	%idle (elevé)	le problème est ailleurs (application, IO, mémoire)
Temps CPU user trop important	vmstat mpstat -P ALL sar -u iostat -c	Rapport %user/%system élevé	- Revoir la logique applicative des processus user detéctés - Reordonnancer les processus (sur différents horaires) pour répartir la charge - Utiliser un plan de ressource
Temps CPU système trop important	vmstat mpstat -P ALL sar -u iostat -c	Rapport %system/%user élevé	- Identifier des problèmes d’IO et/ou de mémoire virtuelle
run queue size > 2x#CPU	sar -q vmstat	runq-sz (sar) r (vmstat)	- Identifier des problèmes d’activité swap - Système sous dimensionné
"trashing" : changement de contexte des processus trop important	vmstat	cs	- revoir la configuration de la mémoire (Mémoire virtuelle, Swap, SGA des bases)

Analyse d’une contention mémoire

Avant de présenter le récapitulatif des commandes, un petit rappel sur la swap. La swap est une mémoire de masse située sur disque (partition, fichier), elle s’ajoute à la mémoire physique (RAM) pour former la mémoire virtuelle.

Lorsque le système n’a plus besoin de données en mémoire physique, il réalise une opération de swap-out (ou Page Out). C’est à dire qu’il copie l’information de la mémoire physique à la swap. Logiquement, si cette information n’est plus nécessaire, elle sera sortie de la swap à terme.

En revanche, si l’information disponible dans le swap est de nouveau nécessaire pour un processus, alors il va y avoir une opération de swap-in (ou Page In) consistant à réintégrer cette information en mémoire physique.

Un système qui réalise des swap-out (so dans vmstat) sans swap-in (si dans vmstat) est un système ayant un comportement normal.

A noter que Linux utilise un cache swap, c’est à dire une zone mémoire réservé au swap-out des pages mémoires ... en mémoire ! Ceci afin de minimiser le coup des swap-in.

En revanche, un système ayant un fort volume de swap-out ET de swap-in doit susciter la curiosité. Cela signifie que le système passe une grosse partie de son temps à rentrer et sortir des informations du swap. Le swap étant sur disque, cela génère beaucoup d’opérations d’entrées/sorties.

Symptôme	Détection	Paramètre déterminant	Mesures curatives
Swap utilisé trop important (80% de la taille du swap)	/proc/meminfo free	rapport swapFree/swapTotal proche de 0	Si le phénomène est constant, ajouter de la mémoire physique
Taux de PageIn/PageOut important	vmstat sar -B	swap (si/so) pgpgin/s et pgpout/s	- SGA surdimensionnée pour tenir en mémoire physique (nécessitant beaucoup d’échanges). Dans ce cas, réduire la SGA, utiliser les HugePages, vérouiller la SGA en mémoire physique avec LOCK_SGA en paramètre d’instance. - Analyser la SGA pour réduire l’utilisation de pool non utilisés et sous-utilisés (mieux ... implémenter ASMM). - Analyser la PGA vous identifier des dépassements de capacité (v$pgastat)
Nombre de pages mémoire inactives faible	sar -R /proc/meminfo	frmpg/s Active/Inactive (dans meminfo)	- Rajouter de la mémoire

Analyse d’une contention IO

Les conclusion d’une analyse de contention IO doit toujours être remise en place dans son contexte. Effectivement, les unités de stockage fournies par des tiers (SAN/NAS EMC² Hitachi NetApp etc.). utilisent des mécanismes de répartitions des données sur de nombreux disques. Ces informations vont quelque peu dénaturer les résultats des outils de stat. Dans ce cas, utilisez par préférence les outils fournisseurs.

Quoiqu’il en soit, veillez toujours à :
répartir les disques rapides sur des contrôleurs de disques rapides
positionner les fichiers ayant des sollicitations plus importantes (control file, redo log) sur des disques rapides.

Symptôme	Détection	Paramètre déterminant	Mesures curatives
Fort volume de requêtes sur tous les périphériques	iostat -d -x	r/s w/s (élevés) rrqm/s wrqm/s (élevés)	Incapacité du système à tenir la charge IO - Augmenter le nombre et/ou la capacité des canaux accédant aux périphériques de stockage
Taille de la file importante sur tous les périphériques	iostat -d -x	avgrq-sz et avgqu-sz (élevés)	Incapacité du système à tenir la charge IO - Augmenter le nombre et/ou la capacité des canaux accédant aux périphériques de stockage
Fort volume de requêtes sur N périphériques	iostat -d -x	r/s w/s (élevés) rrqm/s wrqm/s (élevés)	- Volume en IO mal équilibré sur N périphériques. Répartir les fichiers sur d’autres axes - Utiliser ASM
Taille de file importante sur N périphériques	iostat -d -x	avgrq-sz et avgqu-sz (élevés)	- Volume en IO mal équilibré sur N périphériques. Répartir les fichiers sur d’autres axes - Utiliser ASM
Temps d’attente importants et taille de la file d’attente des IO faible	iostat -d -x	await(elevé) avgrq-sz et avgqu-sz (faibles)	- Vérifier l’utilisation des IO Asynchrones, sinon utiliser IO_SLAVES dans Oracle - Vérifier le matériel, cela peut constituer un indicateur de matériel déféctueux