VMware Esx et sa ram

afin d’éviter VMware Esx et ça rame

Avant de lire ceci, il est bien d'avoir lu l'Article complet sur le sympathique ESX

---

Intro

Voilà les ptis gars, ce mois-ci dans mes diarrhée verbales qui vous serviront de cadeau de Noel, nous allons nous pencher sur l’utilisation fort étrange de la Ram sous VMware, (Complexe j’ai entendu là dans le fond….) donc pour tout savoir sur la gestion de la mémoire sur ESX 2.X vous avez deux options, soit boire un concentré de connaissance VMware ESX ce qui est pas disponible partout. (cela dit quand même plus accéssible semble t'il que des casquettes VMware) Soit vous taper la longue et pénible lecture qui va suivre. Bon vous n’êtes pas sans savoir que je continue mon long et pénible régime.. Donc on va boire de l’eau pour accompagner cet article (et sans Ricard je vous en conjure)… Coté musical, je n'ai meme pas besoin de vous en parler, le dernier opus de System of a Down vient de paraitre, et suffit à ma joie depuis des semaines. en plus chez SoaD il sont moins pénible que chez les Virgin, Fnac et autre pourfendeurs de DADVSI les singles sont écoutables completement et quasi dignement en ligne.. Merci SOAD. Mais reprenons,  aujourd’hui les enfants on va ‘expliciter lhaaa’ (vanne locale, ne prenez pas peur) comment VMware gère et utilise la mémoire Vive, on remercie Mr ‘X’ d’une société de Bières fort connue, et qui a souhaité rester anonyme (et non !! c’est pas en raison de la marque de la bière qui n'est, cela dit, tout de même pas une sympathique bière trappiste) et qui m’a poussé sur la voie de cet article. Prêt un, deux, on y va….

La mémoire, le nerf de la guerre.

Quand on a réussi à installer VMware et que l’on découvre pour la première fois l’onglet memory au hasard du clickodrome, Il faut bien avouer qu’on est frappé d’effrois…mon dieu qu’est que c’est que tout ces petits graphs sympathiques … n’ayez pas peur on va commencer à les passer en revue !

On se retrouve donc avec 2 grands blocs :

System Summary : Dans un premier temps c’est de loin le plus intéressant, il va nous renseigner sur l’état général de notre serveur ESX ainsi que sur la globalité de l’utilisation mémoire de nos machines virtuelles, et surtout de ce qu’il va rester de libre pour de nouvelles machines. Virtual Machine : Là, c’est effectivement plus spécifique aux machines virtuelles, on verra plus tard que c’est une zone importante pour connaître la santé individuelle de ces méméres. Mais dans un premier temps, avant de s’occuper de savoir comment que ça marche, voyons les champs du système summary en détail..

Pour savoir ce qu’il utilise vraiment, il faut en fait jeter un œil au fichier /prod/meminfo.  C’est là qu’on se rend compte que la Ram active ici, allouée quoi, n’est que de 50 mo et qu’il y a 65 mo de Cache.


Donc active + buffers – cache = grosso modo Ram utile mais on sait donc maintenant que la mémoire allouée cache est ‘grattable’ même si les puriste dirons mais c’est génial le cache car quand je relance mozilla c’est instantané… heuu oui certes, mais bon sur une console VMware ça perd de son prestige. Ici on a grosso modo 188 Mo d’utilisé, et on pourrait gagner 65Mo si on était ric et rac... Mais de toute façon, on s’en fout, cette Ram est belle et bien déja perdue pour notre cher ESX… veillez juste à ce que la console soit bien dimensionnée, cela vous évitera d’avoir la mauvaise impression que les VM rament alors qu'en fait il n'en est rien.

Reprenons la suite, Virtualisation :


La virtualisation c’est ce que nous coûte en Ram le fait tourner les machines virtuelles, il faut savoir que ça coûte dans les 54 Mo de Ram par machine virtuelle et qu’il faut rajouter 10 Mo par vCpu supplémentaire (avec l’option VMware SMP)…, mais c'est pas tout, si on dépasse les 512 Mo sur une VM, rebelotte une taxe de 32Mo par bloc de 512Mo supplémentaire, et qu’en plus de tout cela, VMware notre VMKernel lui aussi a besoin de Ram pour tourner, 24Mo, vous me direz c’est pas énorme pour ce que ça fait … donc sachez-le, si vous prévoyez une machine de 256 Mo, elle boulotera déjà de base 256+54 Mo… et une Bi-Cpu d'un Go aura besoin de  1024 + 54 + 10 + 32 =  1120 Mo. Mais on va voir plus loin que c’est pas si simple en fait, ca déjà c'est la mémoire maxi que peut boulotter la virtualisation cela veut dire que c'est ce qu'elle peut prendre au maximum et qu'il faut prévoir, ce n'est pas ce qui peut etre utilisé dans la réalitée.

Shared Common et Virtual Machines.

Mémoire utilisée par VM Machine elle-même… et là aussi ma fois c’est alambiqué. On pourrait croire que si je file 512 Mo à une bécane, monsieur VMWARE va prendre 512 Mo et Basta ... et bien non … déjà il n’attribue que la mémoire réellement utilisée, si vous avez une VM qui fait 512 Mo de Ram, mais que dans le task manager vous voyez que vous n’utiliser que 256 Mo, et bien déjà Mr le Vmkernel ne vas attribuer que 256 Mo de Ram, déjà c’est une bonne nouvelle cela veut dire qu’on peut globaliser une utilisation exceptionnelle de mémoire, mais c’est pas tout VMware va mettre en commun les pages de mémoire identique, le fameux Shared Common (et hop une patente), prenons l’exemple suivant pour votre compréhension (à faire frémir un TO5…)

Soit 2 Serveur, 10 octets de Ram pour le premier et  15 octets de Ram pour le second, et des plages mémoire qui ferait un octet.

Voici un dump de la mémoire
VM1 : 05 93 07 01 01 01 01 00 00 00
VM2 : 89 35 24 56 23 56 01 01 01 01 01 01 01 01 00
Ram total : 25 Byte

Et bien VMware va stocker cela comme ça :
VM1 : 05 93 07
VM2 : 89 35 24 56 23 56
Shared : 01 00
Ram total : 11 Byte

C’est a dire qu’il va stocker les pages mémoire identiques, et va substituer la mémoire demandée au vol, ce qui fait du coup un gain de mémoire substantiel ... Bon ça, c'est dans le monde merveilleux de l'explication imagée, dans la réalité c’est bien malheureusement encore une fois de plus vachement plus complexe que cela. Déjà il doit utiliser un bon paquet de Ram pour savoir quelle plage mémoire doit aller à quel endroit son fameux Memory remapping (et hop une nouvelle patente). Et enfin, il faut savoir que ce n’est pas systématique, c’est un processus qui tourne doucement en background et qui compare les pages mémoires qui ne sont pas sollicitées de toutes les vm afin de trouver des paternes identiques. Il va de soit que le temps d’accès à la mémoire qui est partagée en prend un petit coup, mais c’est quand même un gain que je situerais, au vue de mon expérience, aux alentours de 15% en moyenne, avec bien sûr des scores supérieurs près des 20% si les machines sont aux maximum identiques, par exemple toute une batterie de Windows 2K3 faite à partir du même template (ou nommé gold image si on est fan d'Emile Wandelmer) c’est plus efficace qu’un parc de VM avec du pinguin mélangés à du Windows de toutes versions, et voir même quelques Novell.

Ici dans notre exemple (qui n’est pas fort glorieux)  avec 305 Mo de Ram, il récrée 558 Mo de Ram pour les machines virtuelles, c’est ce que dit la ligne Memory Saving due to Sharing.

Et comme tout bon process qui tourne tranquillement dans le fond, ça prend un certain temps avant que le partage soit optimal, il n'y a qu'a regarder le joli graph donné par vmktree sur une machine volontairement stressée pour se rendre compte rapidement de la chose:


C’est effectivement frappant, il faut bien 2h pour que la mémoire partagée soit à sont apogée, et on voit aussi que si au boot, effectivement la mémoire est sollicitée, une fois en prod c’est tout de même plus calme. Donc pas de stress, avant 2h après un reboot complet, un VMware est une machine qui ne sera pas au meilleur de sa forme pour vous. Mais si ce processus est lent, c'est aussi pour ne pas faire 'chiez' les vm, le but de premier d'Esx est de faire tourner les VM, pas de faire un concours de shared memory. mais soit, si vous voulez vraiment, allez donc un peut chipoter ces valeurs systemes.



Venons en au deuxième graph, Tadaaaaa

Mémoire Réservée:
Attention ce que l'on définit par mémoire réservée, c'est comme son nom l'indique de la Ram et du SWAP réservé par les VM, mais cela ne veut pas dire pour autant que c'est ce qui est actuellement utilisé...mais... Maryse, vous qu'on a pas encore embêté depuis le début de cette article, dites nous exactement à quoi donc que ca peut servir ... cela sert en fait à savoir quelle est la mémoire encore disponible pour d'éventuelles VM.  Mais pourquoi donc Maryse ? imaginons qu'il n'y ai pas de réservation, on a un serveur ESX avec 2Go de Ram disponible pour les VM et 2Go de Swap pour les VM, donc une capacité Théorique de 4 Go de Ram, la dessus j'ai 5 machines de 1 Go mais qui ne bouffent que 512Mo de mémoire réellement, pas de Pbm alors je peux avoir mes 5x512Mo = 2560Mo utilisé... ça roule, maintenant un coup de stresse et mes VM demandent toutes d'utiliser leur Go ... bilan 5x1Go = 5Go et j'en ai que 4... Zut.... patatra....c'est ballot... voilà donc le mécanisme qu'ESX a mis en place. Il réserve donc par défaut 50% de Ram et 50% Swap... même si c'est pas utilisé ... c'est un minima qu'il tient de côté pour chaque VM.  Du coup je ne peux pas démarrer plus de VM que ne me le permet le SWAP+RAM Quand bien même les VM n'utiliserais pas réellement toute leur RAM. Pour les gens vraiment dans le besoin, inconscient ou qui veulent tester plus qu'ils n'ont, cette limitation peut sauter avec une simple variable vmware, mettez voir à 0 /proc/vmware/config/MemRelaxAdmit

Et bien sur ESX utilise la Ram principalement et commence à utiliser le SWAP quand vraiment il ne peut pas faire autrement. Ce qui permet donc théoriquement de faire marcher tourner des VM avec le double de Ram que le serveur ESX n'en contient ... oui certes mais par pitié pas toutes les VM qui utiliseraient la Ram à fond sinon ça swap et fin des performances... (et performance c'est mot qui prend tout son sens dans ce cas la) C'est ce qu'ils appellent l'overcommitement.  On arrive donc aux premières remarques sur le sizing.. le SWAP VMware c'est 1X la taille de la RAM. En mettre plus c'est inutile (voir débile) ou alors on est un amis du swap. Secundo, paramétrer la réservation de Ram minimum non pas bêtement à 50% de la mémoire totale, mais à ce que le système a besoin pour tourner normalement sans processus exité particulier, pour un Windows par exemple, on prendra la valeur que donne la case commit charge/ total, après boot quand le système est calme. Ici par exemple (bon ok vous m'avez eu le printscreen est pas d'un Windows sous ESX.. les autres avez vous trouvé pourquoi ?) c'est une machine qui a 1go de Ram et bien on paramétrera la Mémoire minimale a 400Mo au lieu de 512, ce qui permettra de globaliser plus de mémoire commune et utilisable par toutes les autres VM en cas de besoin au lieux de réserver bêtement 112Mo de Ram exclusivement pour cette VM inutilement. Il va de soit que pour ce genre d'exercice, c'est moins facile quand on tombe sur un système qui boulotte toute la Ram qu'il trouve afin de s'en faire du cache ...(exemple Exchange / Cache ISA ou un bête pinguin)  là ma fois, il faut connaître son applis et définir avec combien de Ram elle se sent a l'aise.

On comprend donc beaucoup mieux ce bargraph qui nous dit ce qui est réservé ou pas en Ram et SWAP et surtout combien de Ram je dispose encore pour démarrer de nouvelles VM.

Virtual Machines:
Alors voyons maintenant le BarGraph dédié à nos chères et petites VM... déjà on retrouve tout à droite la mémoire Ram disponible pour les VM soit la Ram totale de la VM moins la console.


C'est plus les autres champs qui nous intéressent... Private.. c'est ce qui est utilisé par les VM (au fait 3,6Go de Ram Maxi par VM), shared c'est ce qui est utilisé en commun par les VM, bon la on sens que monsieur VMware se répète... mais voilà la nouveauté qui arrive Swapped... En rouge, Rouge couleur du sang, couleur des indiens, couleur du vin, et qui dit vin dit pot de vin, et tout ça c'est politico magouille et je ne sais quoi (je sens que je m'emporte Remi)  Bref du swap les enfant sur les machines de PROD il n'en faut pas sous peine de voir débarquer toujours le systématique petit con qui vient vous dire, sous VMware ça rame. Si il y a du swap, c'est comme tout les autres OS ça rame, ça rame certes, mais dans le cas de ESX ça rame pire encore, parce que monsieur VMware il sait pas ce que vous faites vous a l'intérieur de la VM, il voit juste quelles sont les pages mémoire qui bougent et celle dont on s'occupe peu ... lui il s'en tamponne il peut swapper n'importe quoi à l'aveugle c'est un psychopathe, là ou un os éviterait de swapper un bout du kernel en mémoire, VMware il s'en tamponne le coquillard, s'il a pas bougé récemment, il va pas se priver de le swapper... pour éviter ce carnage, monsieur VMware  a eu une nouvelle idée (et une nouvelle patente de plus, ho et puis merde démerdez vous allez toutes les lire la)  le Balloon driver... alors déjà posons que le ballon driver est installé quand on met les Tools VMware, pas de tools, pas de ballon driver, mais en même temps, qui oserait avoir de la prod sans tools VMware (dites rien, j'ai déjà des noms ...snif)  Mais diantre que fait cet obscur Ballon Driver.. bin c'est simple on va encore une fois imager...

Imaginons une bouteille d'eau en plastique vide.... percer un goulot à son cul.. et introduisez-y dans le goulot et le cul un ballon de baudruche (ou des capote neuves !  si vous n'avez que ça sous la main)... bon maintenant on va gonfler simultanément ces 2 ballons... voilà on se retrouve avec 2 ballons occupant la moitié de la bouteille d'eau chacun... et bien la bouteille d'eau c'est la ram.. chacun a 50%... comment fait t'on pour avoir un ballon plus gros que l'autre, il faut dégonfler un ballon, et gonfler l'autre... c'est ce que fait le ballon driver.

Il va dans une machine gonfler et faire réclamer à l'OS de la Ram, l'OS se sentant stressé va swapper, mais ce coup-ci de façon intelligente, il sait lui ce qui est bien se swapper ... et cette Ram réclamée...va être filée en douce a une autre VM qui elle a vraiment besoin de RAM.... quand le stress est passé, le ballon se dégonfle.

Il est a noter que le ballon se dégonfle automatiquement, alors que le swap (via ESX) n'est déswappé que quand on a besoin de cette Ram swappée. Comme le fait remarquer mon estimé collègue Mr Niol, il s'est pas fait chiez à swapper  avec le mal que ça lui a donné pour déswapper juste après. Mais cela dit l'OS qui a été stressé et a qui on a dégonflé le ballon, lui aussi ne déswappe pas juste pour faire beau, il va attendre qu'on ai besoin des datas.

Donc sachez-le, dans un monde idéal, PAS de JAUNE et PAS de ROUGE jamais !!! ce sont tout deux des indicateur de Swap et donc manque de ram. Et bien sur la dernière partie nous donne ces info PAR Vm, une bonne occasion de voir tout de suite les vm qui on trop de Ram et celle qui swappent a mort...



Reste dans le bargraph Virtual Machine Summary deux informations importantes, Active et Swap IO.... Active c'est la mémoire qui bouge... Mezmerize the simple minded, Propaganda leaves us blinded, I'm just sitting in my car and waiting for my giiiiiiiiiiiiiiiiirl...Iiiiiiiiii'm just siiiiiiitting in my caaaar and waiting for my giiiiiiiiiiiiiiiiirl.. bin quoi vous n"écoutez pas Soad vous ? piste 4, piste 4 !! bon calmons nous et reprenons la mémoire active, en effet vous serez surpris de constater (du moins moi j'y avait jamais songé) qu'en pratique après la phase fatigante et frénetique de boot très peu de Ram est sollicitée au travail sur des serveurs (un file serveur / ou un serveur web). Quand au Swap IO si vous avez du rouge quelque part et qu'ici c'est pas a 0, c'est que c'est en train de swappé a mort (normalement plafoné à 4K)... alors bloquer vite la porte, le petit con qui vient vous dire, sous VMware ça rame, va surement pas tarder.

Pour ceux qui n’aiment pas les bargraph, toutes ces infos sont disponible dans le détail mémoire des vm, sous le mui ça ressemble a cela :

On y retrouve du côté ressources (à gauche), le maximum possible, c’est à dire la mémoire totale qu’on a donné à cette VM, le minimum, c’est la Ram non partageable que va se réserver ESX pour cette Vm (comme on peut le constater ici, bêtement les fameux 50%),  et alors de l’autre côté les valeurs réelles en ce moment, à savoir la mémoire utilisée 652 Mo, celle qui bouge 117 Mo, celle qui est partagée avec les autres VM, 215 Mo, enfin le sombre tableau des Reclaimed Memory.. ici 30 Mo de Swap sur disque et 218 Mo de Balloon driver réclamé à ce pauvre os, et enfin la virtualisation, qui ne nous coûte que 49 Mo en ce moment ici… le puriste linuxien allergique au clickodrome peut retrouver tout cela en 'catan' le fichier /proc/VMware/vm/numérodelavm/mem/status

  % cat /proc/VMware/vm/204/mem/status
    vm  status               wait    shares  min         size %active  target      max         overhd
   204 dynamic no     1280   98304  124924  58    56           124924  131072   32768

D'une façon générale, pour ceux qui veulent tout savoir de la Ram d'une VM cat /proc....../mem c'est votre ami, pour tous le détail suivez ce lien

Et alors les fin observateur on remarqué … Le con il a pas parlé des Shares !!! bin oui je l’ai pas fait ... on y vient maintenant… donc comme vous maîtrisez déjà ESX, vous savez que on peut privilégier une VM par rapport à une autre via les Shares, bin ici pour l’allocation de Ram c’est pareil.

Admettons 2 VM, une de Prod, une de Test…. De chacune 512 Mo maxi et qui n’en utilise chacune actuellement que 256 Mo… avec 10.000 de shares chacune.  Et bien sûre comme le monde est cruel le serveur ESX ne dispose lui que de 640 Mo de Ram et donc de 640 Mo de Swap …(bon avant que vous vous affoliez, oui j'ai raté mon graphique et je n'ai plus le courage de le refaire, donc au lieux de 1600, comprenez 1280 merci)

Si tout d’un coup, par le plus grand des hasards les 2 vm on tout à coup besoin de leur 512 Mo, VMware va répartir la Ram qui lui reste équitablement entre les 2 vm…. Mais a partir de 320 Mo de Ram chacune il va se trouver le bec dans l’eau il lui manque 128 Mo de Ram pour chaque VM, il va tenter le balloon puis le swap.. et vous êtes dans le CACA, vos 2 vm rament, et le con va pas tarder encore une fois a vous emmerder…

Solution… 10000 de share pour la VM de Prod… 1000 pour la VM de test… Ce la veut dire que ESX va donner 10x plus de Ram à la prod qu’à la machine de test quand celle-ci vont lui en demander… et dans ce même cas de figure. la prod va rapidement sucer la Ram libre et la pauvre machine de test elle va swapper a mort. Mais vous vous en fouter, vos user son heureux… bon mais le con débarquera tout de même, car souvent le con est un programmeur sur la machine de test.

Bon il va de soit que les shares son communs à toutes les vm lancées et qu’il faille être moins extrémiste dans la répartition que je ne l’ai été dans les exemples. Moi j’utilise Un genre 75% de share pour la Prod et 25% pour les Test ou autre……
 

Maintenant pour ceux qui veulent savoir 'in deep' comme on dit, il y a un très bon article en langue de Shakespeare qui parle de toute cela, certes il est pas tout frais, mais le sharing, et nos amis les swap y sont longuement décortiqués certes d'une façons plus austère, mais aussi des plus complète.

Planning et estimation de la RAM

Il y a 2 cas de figure, le planning pour reprendre des machine existante physiquement et le planning qu'on fait pour mettre en place de nouvelles machines, le premier est pour ainsi dire beaucoup plus aisé ... et dieu sait qu'on aime les tâches aisées.
Pour faire son travail correctement, l'idéal c'est d'arriver sur la machine après qu'elle nous ai fait une bonne semaine, de bons et loyaux services, sans reboot, ni crash, là il nous suffit d'un coup de Task Manager pour tout connaître :

Dans le cas présent on a une bonne machine qui contient 1 Go de Ram ( Physical Memory / Total )... dans ces 1 Go au maximum notre Windows n'a utilisé que 521 Mo (Commit Charge/Peak) et actuellement, il boulotte tranquillement 384 Mo (Commit Charge / total) Si par hasard vous voyez que commit charge total > Physical memory total : ne vous y fiez pas, cette bécane manque de Ram à mort. Mais reprenons… Donc si je veux estimer cette bécane, je dirais qu'on va lui filer sous VMware 640Mo de Ram totale ( histoire de prévoir le pic de Ram à l'aise ) que je vais demander 384 Mo de Ram Minimum comme ça, elle tournera nickel par tous temps... Je n'oublie pas bien sûre de rajouter pour mon serveur ESX 54 Mo, car elle n'a qu'un CPU et 32Mo car je dépasse 512 Mo ... bilan budget Ram de la VM et de L'ESX Pour cette bête : 640 + 54 + 32 = 726 Mo, Bref 300 Mo de gratté par rapport a une idiote transposition réel vers virtuel de la Ram totale. Mais ce n'est pas tout, si j'ai d'autres Windows de la même trempe je peut baisser les 640Mo de 10 à 20%... Admettons que j'ai 5 fois cette bécane sur un serveur ESX et 3 de 512Mo qui bouffent 200mo mais montent bien a 350Mo en pic... Le bheu bheu de basse aurait tapé 6,5Go et eu été content (la j'aurai payé pour voir la pauvre tête du mec qui signe les chêques)

Ce que moi je calcule c'est ça (accrochez vous et choppez une calculette):

Déjà la virtualisation :
Total de Ram pour l'esx : 795 Mo

enfin pour la Ram des VM

Total 3700  + 975 Mo ... mais c'est pas fini ... si on fait ça, on se fait couillonner des 6% de Ram free donc ((3700 + 975) – 192 de console )  + 6% = 4,751 Go... bon après on arrondit à la barrette, n'ayant pas de possibilité d'achat de Ram au kilo... ça c'est mon calcul, le puriste râle déjà que +6% c'est pas pareil que -6% soit... je le concède.. la shared memory aussi c'est une estimation, mais c'est grosso merdo ce qu'explique M. VMware dans sa doc http://www.VMware.com/pdf/esx25_admin.pdf page 419. Sauf qu'eux calcul a l'arrache la mémory sharing sur le tout alors qu'en fait, d'après mes benchs, elle tourne de 10 a 20% de 'forcement' la Ram assignée aux VM. Si il y a des champions de l'Excel, je suis preneur du feuille bien sentie ...

Bon alors la c'est chouette mais, ça c'est typiquement le cas d'école que je vous déconseillerais de mettre en prod tel quel.... Primo... on est à 8 Vm, si un con veut une Vm de plus, on passe a 9 et on conseille donc de passer à 272 la Ram réservée a la console (et son swap console aussi n'oubliez pas, j'entend des cris dans le fond là ... ) et si on rajoute cette Vm, et bien on a déjà plus de Ram vierge... bref sachez-le... vous serez dans le cas de reprise de l'existant toujours rick et rack...

Secundo, à ce tableau idyllique, vient se greffer d'autres problèmes potentiels ... Déjà les Linux, ces pervers petit sphénisciformes qui boulottent systématiquement la Ram disponible, c'est que ça flingue un peut le concept ...je n'ai pas de solution élégante (du moins je n'en n'ai pas encore trouvé, mais j'attends vos remarques) un MRTG sur la valeur nommée 'active' et 'buffers' dans /proc/meminfo et on reprend la valeur moyenne plus un chouilla en Ram minimale sous VMware et la valeur Pic plus un chouilla en Ram allouée. Pour Novell Netware, j 'ai pas la queue d'une idée...

Viennent enfin la catégorie pénible des Ram Bouloteurs.... j'ai cité ISA, SQL, Oracle et autres Exchange qui boulottent impunément toute Ram qui est discrètement en train de se payer du bon temps à l'ombre d'un slot SDRAM, et tout cela pour bêtement s'en faire du cache,  mais là dans le cas d'un système consolidé, il va falloir que ces programmes se la mettent sur l'oreille cette boulimie de Ram. Pour tout ce qui est bases, chopper le db admin qu'il vous dise ce qu'a vraiment besoin sa base (si tenté qu'il y en ai un sur la planète qui sache vraiment ce dont a besoin une base),c'est par la peine que ça se vautre dans la Ram pour rien , pour Exchange ça se tune, avec un peu de saine lecture. Quant à notre ami l'ISA le cache, ça se paramètre et par défaut c'est effectivement 50% de la Ram.

Pour planifier des nouvelles machines... moi je demandais à Garcimore, c'était le plus simple, mais il est décédé maintenant... effectivement donc la tâche n'est pas des plus simple, on a les mêmes problèmes que pour planifier une migration Real to Virtual sauf qu'on sais pas regarder avant .... bref je conseille de vous faire des stats dès que vous croiser un serveur même non virtualisé, ça aidera pour plus tard.

De toutes façons, sachez que quoi que vous fassiez 'la nature n'aimant pas le vide(tm)' votre serveur aura tôt ou tard une tendance à la saturation, à vous de gueuler et de remballer fermement le petit de con de programmeur en lui expliquant que c'est pas parce que c'est virtuel qu'on peut se permettre de bourrer des VM de test à l'infini au détriment du bien être des vrais VM.

Allez on récapitule avant d'aller au lit

• Pas de Rouge
• Pas de Jaune
• On ne laisse pas bêtement 50%
• Les share c’est pas pour les chiens
• On tente de garder les VM le plus uniforme possible
• On ne mise pas sur l’overcommitement
• Les Tools Bordel les tools !!!
• On est généreux avec le budget Ram de L'eSx