Optimisation des VM Debian dans un cluster VmWare ESX
Celle là, elle m'a tellement bien occupé que je me dois de vous la raconter...
TL;DR: If you're using a Linux ou Windows VmWare VM on an ESX (clustered or not) with a dedicated Disk Bay, and you experiment slow disk access and speed, you MUST set 1 CPU with 4 Cores in your VM.
Depuis quelques mois, on nous remonte un problème de performance sur la plateforme web que nous avons créé. Cette plateforme se compose de plusieurs VM Debian sous un cluster VmWare ESX.
Comme un gros malin j'ai oublié il y a 4 ans de coller les datas MySQL sur la partition de données d'un des serveurs web mutualisé. 4 ans plus tard, la partition de 10go est pleine quand MySQL n'a plus assez de mémoire et doit swapper.
1ere correction augmenter la taille de la mémoire. On est passé de 4Go (lol) a 16Go. J'ai ensuite passé une petite journée à optimiser les tables critiques et les paramètres du serveur à l'aide du bien utile "mysqltuner" (apt-get install mysqltuner).
Une fois lancé, il vous demande un compte admin sur la base de données et la passe au peigne fin pour y trouver des axes d'amélioration (et il en trouve !).
Le problème de cache résolu j'ai voulu déplacer les datas mysql vers la partoche de données et là ce fut le drame. Les taux de transfert de disque étaient catastrophiques...
Genre ça :
Oui... 4 MB/sec... Le drame quand on sait qu'un vieux disque dur mécanique ou qu'une clé USB3 vous sort du 60MB/S.
J'ai d'abord cru à un problème sur la baie de disque mais sur certaines VM l'infra torche du feu de dieu :
...
Je ne vous cache pas que j'ai passé plusieurs jours à comprendre, jouant avec les charges serveurs, la mémoire, les réservations de processeurs, basculant les VM d'un ESX à un autre dans le cluster et même en demandant la migration des données sur un autre datastore mais rien...
Et puis en regardant un à un les screenshots je me suis aperçu d'un truc... Le problème semblait cibler uniquement les VM avec 2 processeurs. Celles disposant de 4 processeurs n'étaient pas touchées.
J'ai fait ajouter 2 CPU à la fameuse VM et BAM :
Incroyable... J'attends que le responsable système rentre et je vais lui demander de m'expliquer pourquoi ça fait ça.
EDIT : En fait c'est juste le fait de rebooter qui donne le boost de performance sur les disques. Comme si le contrôleur virtuel de disque saturait au bout d'une journée... Je continue donc à chercher...
EDIT2: [SOLVED] Le problème venait de la configuration de la VM. Tout fonctionne mieux avec 1 CPU de 4 coeurs plutôt que 2 CPU de 1 coeur. Le nombre de CPU semble avoir une influence mais pas le nombre de coeur... Etrange mais... OK.
TL;DR: If you're using a Linux ou Windows VmWare VM on an ESX (clustered or not) with a dedicated Disk Bay, and you experiment slow disk access and speed, you MUST set 1 CPU with 4 Cores in your VM.
Depuis quelques mois, on nous remonte un problème de performance sur la plateforme web que nous avons créé. Cette plateforme se compose de plusieurs VM Debian sous un cluster VmWare ESX.
Comme un gros malin j'ai oublié il y a 4 ans de coller les datas MySQL sur la partition de données d'un des serveurs web mutualisé. 4 ans plus tard, la partition de 10go est pleine quand MySQL n'a plus assez de mémoire et doit swapper.
1ere correction augmenter la taille de la mémoire. On est passé de 4Go (lol) a 16Go. J'ai ensuite passé une petite journée à optimiser les tables critiques et les paramètres du serveur à l'aide du bien utile "mysqltuner" (apt-get install mysqltuner).
Une fois lancé, il vous demande un compte admin sur la base de données et la passe au peigne fin pour y trouver des axes d'amélioration (et il en trouve !).
Le problème de cache résolu j'ai voulu déplacer les datas mysql vers la partoche de données et là ce fut le drame. Les taux de transfert de disque étaient catastrophiques...
Genre ça :
J'ai d'abord cru à un problème sur la baie de disque mais sur certaines VM l'infra torche du feu de dieu :
On a des bursts à 783 MB/s soit 2x plus rapide qu'un SSD, ce qui est tout à fait normal puisque notre baie est composée en grande partie de SDD en RAID5. La baie de disque était donc hors de cause...
J'ai alors pensé à un problème de kernel spécifique à linux, mais même avec le dernier kernel et en ajoutant l'instruction "elevator=noop" les débits restaient pitoyables... Qui plus est, d'autres VM sous Linux ne semblaient pas souffrir de ce problème de disque.
Je ne vous cache pas que j'ai passé plusieurs jours à comprendre, jouant avec les charges serveurs, la mémoire, les réservations de processeurs, basculant les VM d'un ESX à un autre dans le cluster et même en demandant la migration des données sur un autre datastore mais rien...
Et puis en regardant un à un les screenshots je me suis aperçu d'un truc... Le problème semblait cibler uniquement les VM avec 2 processeurs. Celles disposant de 4 processeurs n'étaient pas touchées.
J'ai fait ajouter 2 CPU à la fameuse VM et BAM :
Incroyable... J'attends que le responsable système rentre et je vais lui demander de m'expliquer pourquoi ça fait ça.
EDIT : En fait c'est juste le fait de rebooter qui donne le boost de performance sur les disques. Comme si le contrôleur virtuel de disque saturait au bout d'une journée... Je continue donc à chercher...
EDIT2: [SOLVED] Le problème venait de la configuration de la VM. Tout fonctionne mieux avec 1 CPU de 4 coeurs plutôt que 2 CPU de 1 coeur. Le nombre de CPU semble avoir une influence mais pas le nombre de coeur... Etrange mais... OK.
Commentaires
Enregistrer un commentaire