System/Performance

Préambule

Ces préconisations sont aussi valables dans leur quasi-intégralité pour les serveurs web et ftp.

Ces préconisations ne sont pas les seules nécessaires pour installer Oracle. Voir Source0 pour la liste complète des prérequis.

Objectif

Diminuer les temps de réponse des requêtes (évidemment).

Buts

Le principe est d'éviter _à tout prix_ les I/O wait (voir graphe "CPU usage" dans Munin). Pour celà, il faut principalement :
* que la VM ait suffisamment de mémoire pour faire tourner tous les processus nécessaires (Oracle & friends)
* qu'il reste suffisamment de mémoire pour le cache disque
ce qui se manifeste par une utilisation très faible de la swap (<200MB) et, dans top, wa <2%.

Points bloquants :
* "blocage" de VMWare sur l'utilisation maximale de la RAM dans la VM => à ne jamais utiliser sur une VM hébergeant une base de données.
* quantité de mémoire totale (SGA/PGA/UDA) configurée dans Oracle supérieure à 75% de la RAM affectée à la VM (idéalement plutôt 66%).
* trop de swap (maxi 4GB sur EL5 ; avec davantage de swap les performances s'écroulent !)
* ballon VMWare mal réglé (prenant trop de RAM) => il faut le régler à max. 3GB
* pas assez de RAM (il faut compter entre 4GB et 32GB selon la taille de la base)

Méthode de base pour le diagnostic :
* "free -m" => doit montrer suffisamment d'espace pour les buffers, et moins de 200MB de swap utilisée
* "top" => ne doit montrer que très peu d'I/O wait lors de requêtes Orphea complexes (moins de 5% en pointe, moins de 1% en tout)

Si beaucoup de swap est utilisée, si beaucoup d'I/O wait sont présents (10% est déjà une valeur anormale), et si les requêtes semblent (subjectivement) longues, il faut tout d'abord :
* vérifier la quantité de swap totale (maxi 4GB sur EL5)
* vérifier le ballon, et les contraintes d'occupation de mémoire côté VMWare. En particulier, ne pas contraindre la mémoire utilisée dans la VM via VMWare, et régler le ballon à 3/4 de la swap, pas plus, soit 3GB maximum.
* vérifier que l'ordonnanceur utilisé est bien noop (paramètre de boot : elevator=noop)
* vérifier que le paramètre swappiness est bien à 0 (# sysctl vm.swappiness)
* vérifier qu'Oracle n'est pas configuré pour une utilisation mémoire trop élevée. Restreindre la mémoire totale utilisée par Oracle à 66%-75% de la VM.Pour celà, éditer /oracle/dbs/initorphcore.ora - par exemple sga_target=10G

Notes

L'I/O Wait est "normal" dans certaines situations exceptionnelles : redimensionnement de datafile Oracle, forte écriture avec dd, etc. Dans une situation normale, l'I/O wait doit être inférieur à 5% ; en pratique, on arrive quasiment toujours à descendre en dessous de 1%.

Adaptation de la configuration aux préconisations pour déployer Oracle sur EL5

Source0 : http://www.redhat.com/f/pdf/rhel/Oracle-10-g-recommendations-v1_2.pdf

• 4GB de ram minimum par VM Oracle (16 ou 32GB sont recommandés pour les grosses bases)

• 4GB de swap *maximum* dans chaque VM

• réglage des paramètres de boot du kernel:
  ** ajouter "divider=10 notsc iommu=soft elevator=noop" dans la ligne "kernel" dans /etc/grub.conf
  
  * réglage de la couche "vm" :
  tout d'abord, vérifier qu'aucun de ces paramètres n'a été déclaré dans /etc/sysctl.conf ; ensuite :
  echo "vm.swappiness=0" >> /etc/sysctl.conf
  echo "vm.dirty_background_ratio=3" >> /etc/sysctl.conf
  echo "vm.dirty_ratio=15" >> /etc/sysctl.conf
  echo "vm.dirty_expire_centisecs=500" >> /etc/sysctl.conf
  echo "vm.dirty_writeback_centisecs=100" >> /etc/sysctl.conf
  echo "kernel.shmmax= 8589934592" >> /etc/sysctl.conf # pour 16GB seulement
  echo "kernel.shmmni=4096" >> /etc/sysctl.conf
  echo "kernel.shmall=4194304" >> /etc/sysctl.conf
  echo "net.core.rmem_default=262144" >> /etc/sysctl.conf
  echo "net.core.wmem_default=262144" >> /etc/sysctl.conf
  echo "net.core.rmem_max=4194304" >> /etc/sysctl.conf
  echo "net.core.wmem_max=262144" >> /etc/sysctl.conf
  echo "net.ipv4.tcp_rmem= 4096 262144 4194304" >> /etc/sysctl.conf
  echo "net.ipv4.tcp_wmem= 4096 262144 262144" >> /etc/sysctl.conf
  echo "net.ipv4.ip_local_port_range=\"1024 65000\"" >> /etc/sysctl.conf

Adaptation du ballon VMWare aux prérequis

  * Source1 : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003586
  * Source2 : http://www.vmware.com/pdf/vsphere4/r40/vsp_40_resource_mgmt.pdf

En résumé, ne pas dépasser, pour le ballon, la taille de la swap moins une sécurité.

On va donc fixer le ballon à 3GB pour les VMs ayant 4GB de swap. Pour celà, il faut ajouter
sched.mem.maxmemctl = 3072
dans le fichier vmx de la machine virtuelle.

Taille des systèmes de fichiers et fragmentation

Ne pas dépasser 80% d'occupation pour chaque système de fichier, sous peine de fragmenter les données.

L'implication en cas de fragmentation est que les données ne seront plus localisées de manière logique, donc les accès nécessiteront des mouvements de tête de lecture/écriture, augmentant les I/O wait.

NB: Il n'y a pour l'instant aucune façon de défragmenter ext3/ext4 en ligne, la seule façon de défragmenter ces systèmes de fichiers est de créer un système de fichier plus grand et de recopier les données dedans ce qui induit nécessairement une interruption de service. D'où la nécessité de ne jamais fragmenter le système de fichiers.

Quelques pistes supplémentaires

• HugePages => ceci nécessite une investigation supplémentaire, ainsi qu'une procédure de récupération en cas de crash Oracle.
  # pour 16GB :
  # echo "vm.nr_hugepages=4096" >> /etc/sysctl.conf
  
  * utiliser un kernel EL5.6 - en effet, le kernel 5.4 n'est pas complètement optimisé pour la virtualisation. Les kernels 5.6+ et 6.1+ le sont. A noter qu'il est normalement possible d'utiliser un kernel 5.6 sur un OS 5.4.