System/Performance

Benchmarks

CPU

time echo "scale=5000; a(1)*4" | bc -l > /dev/null

Disk

time dd bs=1M count=5000 if=/dev/zero of=/tmp/dd.test
time dd bs=1M count=5000 if=/tmp/dd.test of=/dev/null
rm -f /tmp/dd.test

Network

Server

nc -v -l 2222 > /dev/null

Client

time dd if=/dev/zero bs=1M count=1000 | nc SERVER_HOST_NAME 2222 -v

Principes

Le principe est d'éviter 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 longues, il faut tout d'abord vérifier :

• la quantité de swap totale (maxi 4GB sur EL5)
• 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.
• que l'ordonnanceur utilisé est bien noop (paramètre de boot : elevator=noop)
• que le paramètre swappiness est bien à 0 (# sysctl vm.swappiness)

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.