System/Performance - Revision history

Eadam: /* Benchmarks */

2012-10-15T13:13:38Z

Benchmarks

Eadam at 13:13, 15 October 2012

2012-10-15T13:13:05Z

Eadam at 11:30, 24 June 2012

2012-06-24T11:30:12Z

Eadam: /* Buts */

2012-04-15T09:36:13Z

Buts

Eadam: /* Quelques pistes supplémentaires */

2012-04-15T09:35:17Z

Quelques pistes supplémentaires

Eadam: /* Adaptation de la configuration aux préconisations pour déployer Oracle sur EL5 */

2012-04-15T09:34:54Z

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

Eadam at 09:33, 15 April 2012

2012-04-15T09:33:37Z

Eadam: Created page with "=== 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écessaire..."

2012-04-15T09:32:15Z

Created page with "=== 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écessaire..."

New page

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

@@ Line 5: / Line 5: @@
   time echo "scale=5000; a(1)*4" | bc -l > /dev/null
-=== Disks ===
+=== 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
 == Principes ==

← Older revision		Revision as of 13:13, 15 October 2012
Line 1:		Line 1:
		+	== Benchmarks ==
		+
		+	=== CPU ===
		+
		+	time echo "scale=5000; a(1)*4" \| bc -l > /dev/null
		+
		+	=== Disks ===
		+
		+	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
		+
	== Principes ==		== Principes ==

@@ Line 1: / Line 1: @@
-=== Préambule ===
+== Principes ==
-Ces préconisations sont aussi valables dans leur quasi-intégralité pour les serveurs web et ftp.
+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<br />ce qui se manifeste par une utilisation très faible de la swap (&lt;200MB) et, dans top, wa &lt;2%.
-Points bloquants :
+=== Points bloquants ===
 * "blocage" de VMWare sur l'utilisation maximale de la RAM dans la VM =&gt; à 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%).
@@ Line 22: / Line 14: @@
 * pas assez de RAM (il faut compter entre 4GB et 32GB selon la taille de la base)
-Méthode de base pour le diagnostic :
+=== Méthode de base pour le diagnostic ===
 * "free -m" =&gt; doit montrer suffisamment d'espace pour les buffers, et moins de 200MB de swap utilisée
 * "top" =&gt; 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 :
+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 :
-* 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.
+* la quantité de swap totale (maxi 4GB sur EL5)
-* vérifier que l'ordonnanceur utilisé est bien noop (paramètre de boot : elevator=noop)
+* 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 le paramètre swappiness est bien à 0 (# sysctl vm.swappiness)
+* que l'ordonnanceur utilisé est bien noop (paramètre de boot : elevator=noop)
-* 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.&#xFEFF;Pour celà, éditer /oracle/dbs/initorphcore.ora - par exemple sga_target=10G
+* que le paramètre swappiness est bien à 0 (# sysctl vm.swappiness)
 === Notes ===

← Older revision		Revision as of 09:35, 15 April 2012
Line 73:		Line 73:
	=== Quelques pistes supplémentaires ===		=== 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.<br /> # pour 16GB :<br /> # echo "vm.nr_hugepages=4096" >> /etc/sysctl.conf~~<br /><br />~~* 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.	+	* HugePages => ceci nécessite une investigation supplémentaire, ainsi qu'une procédure de récupération en cas de crash Oracle.<br /> # pour 16GB :<br /> # 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.

@@ Line 11: / Line 11: @@
 === Buts ===
-Le principe est d'éviter _à tout prix_ les I/O wait (voir graphe "CPU usage" dans Munin). Pour celà, il faut principalement :<br />* que la VM ait suffisamment de mémoire pour faire tourner tous les processus nécessaires (Oracle & friends)<br /> * qu'il reste suffisamment de mémoire pour le cache disque<br />ce qui se manifeste par une utilisation très faible de la swap (&lt;200MB) et, dans top, wa &lt;2%.
+Le principe est d'éviter _à tout prix_ les I/O wait (voir graphe "CPU usage" dans Munin). Pour celà, il faut principalement :
-Points bloquants :<br />* "blocage" de VMWare sur l'utilisation maximale de la RAM dans la VM =&gt; à ne jamais utiliser sur une VM hébergeant une base de données.<br />* 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%).<br />* trop de swap (maxi 4GB sur EL5 ; avec davantage de swap les performances s'écroulent !)<br />* ballon VMWare mal réglé (prenant trop de RAM) =&gt; il faut le régler à max. 3GB<br />* pas assez de RAM (il faut compter entre 4GB et 32GB selon la taille de la base)
+Points bloquants :
-Méthode de base pour le diagnostic :<br />* "free -m" =&gt; doit montrer suffisamment d'espace pour les buffers, et moins de 200MB de swap utilisée<br />* "top" =&gt; 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)
+Méthode de base pour le diagnostic :
-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 :<br />* vérifier la quantité de swap totale (maxi 4GB sur EL5)<br />* 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.<br />* vérifier que l'ordonnanceur utilisé est bien noop (paramètre de boot : elevator=noop)<br />* vérifier que le paramètre swappiness est bien à 0 (# sysctl vm.swappiness)<br />* 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.&#xFEFF;Pour celà, éditer /oracle/dbs/initorphcore.ora - par exemple sga_target=10G
+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 :
 === Notes ===

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

@@ Line 23: / Line 23: @@
 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%.
-<span style="color: #339900; font-size: 16px; line-height: 17px;">Adaptation de la configuration aux préconisations pour déployer Oracle sur EL5</span>
+== Adaptation de la configuration aux préconisations pour déployer Oracle sur EL5 ==
-<br />Source0 : http://www.redhat.com/f/pdf/rhel/Oracle-10-g-recommendations-v1_2.pdf
+ 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)
@@ Line 35: / Line 35: @@
 === Adaptation du ballon VMWare aux prérequis ===
-   * Source1 : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003586
+ 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
+ Source2 : http://www.vmware.com/pdf/vsphere4/r40/vsp_40_resource_mgmt.pdf
 <br />En résumé, ne pas dépasser, pour le ballon, la taille de la swap moins une sécurité.