Problèmes intermittents de performance KVM causant des pépins de performance

Nous sommes actuellement hébergés chez un fournisseur d'hébergement qui nous permet de configurer plusieurs machines virtuelles à l'aide de KVM, où chaque machine virtuelle fonctionne sur sa propre boîte physique (c'est-à-dire : un hyperviseur, une VM avec toute la mémoire et le CPU qui lui sont alloués). Récemment, nous avons rencontré de vilains problèmes que nous devions diagnostiquer (il s'agissait de débordements de pile - lol). Dans le cadre de ce processus, nous avons configuré DataDog pour surveiller tous nos serveurs, ce qui nous a permis d'identifier la cause du problème et de le résoudre. Nous l'avons trouvé très utile et l'avons laissé activé. Dans le processus d'apprentissage des outils, nous continuons à constater des temps de réponse lents pendant la journée pour nos sites Web. En activant le traçage APM, nous avons pu réduire le problème à un mauvais temps de réponse de notre cluster MySQL. Parfois, les connexions MySQL prennent 900 ms ou plus pour être créées, et d'autres fois, des requêtes simples comme le réglage de la collation de la connexion ou du fuseau horaire prennent 600 ms ou plus. Des requêtes qui s'exécutent normalement en moins de 800 microsecondes.

Pour diagnostiquer le problème, nous avons configuré des pings vers plusieurs points d'extrémité dans notre cluster, et nous avons deux pings qui tournent régulièrement lentement (4-5s parfois !) qui ne font rien d'autre que de retourner une chaîne (version de PHP/apache) ou de retourner des informations IP du client (.net et version IIS). Nous les avons configurés pour voir si nous rencontrerions des problèmes sous Linux ou IIS sans rien d'autre, et c'est le cas. Curieusement, pendant les périodes où nous avons ces pannes, le CPU des machines est très bas, de même pour le cluster MySQL. Lorsque les requêtes sont lentes, le CPU est très bas, car ces machines se situent généralement autour de 5-6% du CPU la plupart du temps.

Pour essayer de déterminer s'il s'agissait d'un problème de réseau, nous avons configuré des captures à l'aide de Wireshark sous Windows et vidé les paquets tout en décorant les requêtes afin de pouvoir les retrouver facilement dans les vidages de paquets (en fait, nous avons défini une variable MySQL dans la requête qui est une version codée de l'horodatage UTC actuel en microsecondes). En utilisant cette méthode, nous avons pu faire correspondre correctement les longues périodes MySQL dans DataDog APM avec les paquets dans les vidages TCP. Du côté de Windows/IIS, nous avons pu constater que tout le temps était passé à attendre que le résultat revienne du serveur MySQL. Le temps indiqué dans DataDog pour la requête MySQL correspondait donc exactement au temps indiqué dans les vidages de données.

Donc, comme vous pouvez le voir sur les deux captures d'écran, elles correspondent exactement. Pour déterminer si le problème de réseau est survenu du côté de MySQL, nous avons refait le même dump de capture sur la machine Linux et nous avons vu exactement la même chose. MySQL a reçu la requête, et un grand nombre de millisecondes plus tard, il a envoyé la réponse. Il est donc clair que le problème ne vient pas du réseau, mais d'un ralentissement de MySQL lui-même.

Ce qui est vraiment étrange, c'est que ce n'est pas MySQL lui-même qui est bloqué, car la machine sur laquelle j'ai exécuté ces requêtes n'exécutait que des requêtes en lecture depuis l'une de nos machines virtuelles Windows, en tant qu'esclave de lecture. Il n'avait donc pas beaucoup de charge, et pendant la durée des requêtes, la charge du CPU était probablement de 3 % (il a 16 cœurs physiques de CPU avec deux CPU Xeon 8C, et 32 vCores alloués à la VM). Il ne s'agit donc pas d'un problème de charge sur le serveur MySQL et, plus important encore, d'après les vidages TCP, il est clair que pendant que la requête qui nous intéressait prenait beaucoup de temps à s'exécuter, de nombreuses autres requêtes provenant d'autres connexions ont été traitées sans délai.

Pour couronner le tout, nous avons également constaté dans notre journal que l'esclave MySQL est régulièrement en retard, de 30 à 40 secondes sur le maître. Nous avons vu des cas où il avait jusqu'à 110 secondes de retard sur le maître, ce qui n'a aucun sens puisque la machine est peu chargée et qu'elle se trouve sur le même réseau local privé que la base de données maître (et les serveurs web). Parfois, ces retards dans l'esclave se produisent au même moment que les ralentissements, et parfois non.

Donc, maintenant que nous avons déterminé de manière concluante que nous ne pensons pas qu'il s'agisse d'un problème de réseau, nous commençons à penser qu'il s'agit d'une sorte de problème de blocage de thread dans KVM lui-même ? En particulier parce que nous constatons des ralentissements très étranges dans toutes nos machines virtuelles, dont certains n'ont rien à voir avec MySQL (comme le fichier statique PHP hello). Comme nous n'avons aucun contrôle sur la couche KVM, nous ne savons pas sur quelle version elle tourne et comment elle est configurée. Mais plus nous examinons ce problème perplexe, plus le doigt pointe vers KVM comme étant la cause première de ce problème, mais nous n'avons aucune idée de la façon de le résoudre.

Pour illustrer le problème, voici un ping d'une page PHP qui ne fait qu'un écho de 'hello' et ne fait rien d'autre, et les temps de ping de trois serveurs AWS. Vous pouvez clairement voir des pics importants à certains moments.

Maintenant, vous pourriez simplement argumenter, mais c'est du réseautage ! Bien sûr, vous pouvez avoir des problèmes de communication entre AWS et ce serveur pendant la journée. C'est vrai, mais voici un ping pendant EXACTEMENT la même période depuis les EXACTS mêmes serveurs AWS vers une page statique dans Apache, mesuré en millisecondes cette fois (moins à faire que PHP qui doit mettre en serveur même une simple page) :

Donc, comme vous pouvez le constater, ce n'est pas non plus le réseau externe, car le ping du fichier statique n'a jamais été lent. Pas de problème du tout. Nous avons en fait configuré ce fichier statique ping pour qu'il soit exécuté contre une deuxième instance d'Apache sur cette boîte pour s'assurer qu'il n'y a pas de charge sur lui afin d'obtenir une ligne de base. A la fin du ping, vous pouvez voir que les choses ont commencé à devenir un peu folles et que les temps de ping sont très variables. C'est parce que nous venons d'activer PHP dans cette instance et que nous avons servi le même fichier hello.php à partir de cette seconde instance d'Apache pour voir quelle différence cela ferait. Principalement parce que la première instance sert également un trafic réel vers nos blogs Wordpress et nos serveurs publicitaires (trafic de faible volume, mais non nul). Il est donc clair qu'une fois que nous ajoutons quelque chose au mélange qui utilise beaucoup plus de CPU, les choses commencent à aller mal.

Ma question est donc la suivante : quelqu'un d'autre a-t-il déjà rencontré ce genre de problème avec KVM, et si oui, comment l'avez-vous résolu ? Nous sommes sur le point d'abandonner cette solution KVM et de migrer soit vers des machines dédiées (que nous avons abandonnées il y a dix ans), soit vers un nuage privé VMware, soit vers Google ou Azure (deux solutions qui nous coûteront beaucoup plus cher). Mais je ne vois pas l'intérêt de migrer vers une autre architecture en nuage comme Google ou Azure ou un nuage privé VMware, s'ils peuvent avoir des problèmes similaires ?

Des suggestions ?