Changez une chose, mesurez à nouveau. Comment trouver le vrai goulot d'étranglement

Quand une plateforme est lente, le bon de commande le plus rapide est pour plus de tout. Cela marche souvent un peu, coûte beaucoup, et laisse la vraie cause en place pour mordre à nouveau au prochain pic de trafic. L'alternative est moins excitante et bien plus efficace : trouver la seule ressource que la charge de travail attend, y changer une chose, et mesurer à nouveau. Voici la méthode et les outils.

Partez d'un nombre, pas d'une impression

« Le site est lent » ne peut pas être testé. « Le checkout prend quatre secondes au pic du soir et moins d'une la nuit », si. Avant de toucher à quoi que ce soit, fixez le symptôme sur une mesure que vous pouvez répéter : un temps de page depuis l'extérieur, une durée de requête, le temps d'exécution d'un traitement par lots, un débit de requêtes à partir duquel les erreurs commencent. Ce nombre est la façon dont vous saurez si ce que vous avez changé a aidé. Sans lui, chaque changement ressemble à un progrès.

Puis écrivez le chemin que suit l'opération lente : client, réseau, load balancer, serveur web, application, cache, base de données, stockage. Le goulot d'étranglement est quelque part sur ce chemin, et le chemin vous dit où regarder.

Vérifiez chaque ressource pour l'usage, la saturation et les erreurs

Une discipline simple, popularisée par Brendan Gregg sous le nom de méthode USE, garde la recherche honnête. Pour chaque ressource sur le chemin, CPU, mémoire, réseau, stockage, posez trois questions : à quel point est-elle occupée, du travail attend-il en file pour elle, et signale-t-elle des erreurs ? Une ressource peut être peu utilisée et rester le problème si les requêtes font la queue devant elle, donc la deuxième question compte le plus.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Regardez l'usage par cœur, pas seulement la moyenne. Un cœur à pleine charge pendant que les autres sont inactifs pointe vers un goulot d'étranglement mono-thread que davantage de cœurs ne corrigeront pas. Dans vmstat, une run queue (r) durablement supérieure au nombre de cœurs est une saturation.

Mémoire.

free -h
vmstat 1
cat /proc/pressure/memory

La pression mémoire se voit dans l'activité de récupération et le temps de blocage du fichier pressure. Sur une machine virtuelle bien construite, il n'y a pas de swap où se cacher, donc une charge de travail qui a réellement besoin de plus de mémoire qu'elle n'en a échoue bruyamment, ce qui est le résultat honnête : le remède est plus de mémoire ou une application plus sobre.

Stockage.

iostat -x 1
pidstat -d 1

Les colonnes qui comptent sont les temps d'attente moyens en lecture et en écriture et la taille de la file. Le %util est trompeur sur les volumes flash et SAN, qui servent de nombreuses requêtes en parallèle et peuvent afficher une utilisation élevée tout en gardant beaucoup de marge. Des temps d'attente qui montent avec une file qui grandit sont le vrai signal.

Réseau.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Comparez le trafic par membre d'un bond : un membre occupé pendant que l'autre est inactif est un problème de hachage, pas un problème de bande passante. Les pertes et les erreurs dans les compteurs d'interface pointent sous le système d'exploitation, vers les câbles, les optiques ou le switch.

Base de données. Beaucoup de plateformes lentes sont une base de données qui lit sur le disque ce qu'elle devrait lire en mémoire. Sur MySQL ou MariaDB, comparez les lectures logiques avec les lectures qui ont dû aller jusqu'au stockage :

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Si Innodb_buffer_pool_reads (les lectures qui ont manqué la mémoire) croît vite par rapport à Innodb_buffer_pool_read_requests, le working set ne tient pas dans le buffer pool. Le slow query log, avec un seuil raisonnable, vous dit quelles requêtes en paient le prix.

Changez une chose

Une fois qu'une ressource se détache, formulez une hypothèse qui explique le nombre de départ, et faites un seul changement qui la teste : un buffer pool dimensionné au working set, une politique de hachage pour le bond, un cache devant la page coûteuse, une requête qui reçoit l'index dont elle a besoin, une VM redimensionnée pour tenir dans un seul socket CPU. Un changement à la fois, parce que si vous changez trois choses et que le nombre s'améliore, vous ne savez pas laquelle a aidé, et vous avez peut-être gardé deux qui ont aggravé les choses.

Mesurez à nouveau, de la même façon

Répétez la mesure depuis le début, dans les mêmes conditions : même heure de la journée ou même charge synthétique, même test, mêmes outils. Un changement qui n'a pas aidé est aussi un résultat, parce qu'il écarte quelque chose. Annulez-le et revenez aux ressources.

Répétez jusqu'à ce que le symptôme de départ disparaisse ou que le goulot d'étranglement suivant soit quelque chose que l'argent doit réellement résoudre. C'est alors qu'acheter du matériel est la bonne réponse, et vous saurez exactement quelle ressource acheter.

À quoi cela ressemble en pratique

Certains des réglages les plus efficaces tiennent en une ligne. Nous dimensionnons les tampons mémoire des bases de données pour que les données chaudes vivent en RAM et que le flash serve du vrai travail, et chaque serveur en bond que nous construisons hache sur les adresses et les ports pour que les deux liens portent du trafic. Les deux sont des règles permanentes sur chaque plateforme que nous gérons.

Comment nous le faisons

Le travail sur les performances est la façon dont nous exploitons chaque plateforme que nous gérons, pas un produit à part. Nous mesurons à chaque couche, des E/S par volume sur les baies et des compteurs par port sur les bonds et les switches jusqu'aux slow logs sur les bases de données et au chronométrage de l'extérieur vers l'intérieur à travers le CDN, avant de nommer une cause. Des règles permanentes qui sont fiablement justes, comme des bonds qui utilisent les deux liens, du flash traité comme du flash et des VM qui tiennent dans un seul socket, s'appliquent à chaque construction. Quand une plateforme a réellement besoin de plus de capacité, nous vous disons quelle ressource, combien et pourquoi.

Si votre plateforme est lente et que la seule proposition jusqu'ici a été un serveur plus gros, laissez-nous la mesurer d'abord.

Parler à un ingénieur

Related

Voir aussi : Ingénierie de la performance et de la capacité · Serveurs bare metal sur HPE et Dell · Stockage SAN entreprise sur HPE 3PAR, all-flash