Hyper Threading Benchmarking Huge Pages personnalisez vos instances Amazon EC2

Transcript

Nous voilà de retour. J'espère que vous êtes en forme et que vous avez pris un petit café, car cette session est particulièrement dense et riche. Il s'agit d'un deep dive sur EC2, en particulier sur les instances. Nous allons parler uniquement des instances EC2 et de comment optimiser les performances sur ces instances. De quoi allons-nous parler dans cette session ? D'abord, nous allons revenir rapidement sur comment choisir la bonne instance EC2. Ensuite, nous aborderons la performance en général. Nous verrons comment optimiser la performance en termes de réseau, d'entrée-sortie, de CPU, etc. Nous étudierons un certain nombre de techniques avancées pour que vous obteniez le maximum de performances de vos instances EC2. Vous connaissez EC2, tout le monde l'utilise. C'est l'un des premiers services qu'on utilise lorsqu'on commence à découvrir AWS. C'est un service extrêmement vaste, qui fournit un grand nombre de types d'instances. Nous allons les rebalayer rapidement. C'est un service qui inclut des fonctionnalités réseau, de VPC, de load balancing, etc. C'est un service qui vous permet d'acheter ou d'utiliser des instances de différentes manières, soit on-demand, soit des instances réservées, et maintenant des instances spot. Et c'est un service qui a une API extrêmement riche. Il y a beaucoup de choses dans EC2, qui est devenu un service extrêmement complet et, il faut le dire, assez complexe. Rappelons l'évidence. Qu'est-ce qu'une instance EC2 ? C'est une machine virtuelle qui tourne au-dessus d'un hyperviseur, qui s'exécute lui-même sur un serveur physique. Pas de surprise, j'espère. Peut-être ne le savez-vous pas, mais EC2 a été lancé en août 2006. À l'époque, il n'existait qu'une seule taille d'instance, qui était M1. La vie était simple, on choisissait M1, puisque c'était le seul type disponible. C'était il y a un peu plus de dix ans. Il s'est passé beaucoup de choses depuis. Voici une espèce d'arbre généalogique ou de chronologie des instances EC2. Au début, on a allongé la famille M1, on a lancé la famille SC1, et une nouvelle génération M1. Tout cela nous amène fin 2016, avec le lancement des T2X larges et 2X larges, de la famille R4, de la dernière génération d'instances optimisées pour les capacités mémoires. Et début 2017, le lancement de i3, la nouvelle famille optimisée pour les capacités mémoires et les IOs. Il manque encore des types de familles. J'ai oublié de mentionner les instances FPGA, F1, qui sont encore en preview, et les C5 qui ne sont pas encore disponibles mais qui arrivent. Vous voyez, le panorama EC2 s'est grandement enrichi, vous donnant plus de choix, mais au prix d'une certaine complexité. Rappelons que les noms d'instances ont un sens. La première lettre est la famille de l'instance, que nous allons rebalayer rapidement. Le chiffre qui suit est la génération, donc C4 est plus récente que C3, qui est plus récente que C2, etc. La taille d'instance correspond à la puissance de traitement de l'instance en termes de CPU, de capacité mémoire, d'entrée-sortie, etc. Voici quelques-unes des principales familles d'instances EC2. Cela nous amène à la question : quelle famille choisir ? Chacune de ces familles correspond à un cas d'utilisation relativement précis. Par exemple, les instances M ou T sont équilibrées et conviennent à des charges de travail génériques, sans exigences particulières de calcul, de stockage, etc. Les familles C sont optimisées pour le calcul. Elles disposent des dernières générations de processeurs Intel et mettent l'accent sur la performance du CPU. Pour des charges de travail nécessitant du calcul intensif, c'est un bon choix. Les familles D et I sont optimisées pour les entrées-sorties. D pour le stockage dense, donc des grosses capacités de stockage. Si vous avez besoin de stocker de grosses quantités de logs ou de bases de données, la famille D est intéressante. La famille I est optimisée pour le débit et les entrées-sorties. Si vous avez des applications de bases de données qui font des quantités importantes d'accès disque et qui ont besoin de performances élevées et prévisibles, la famille I est intéressante. Ensuite, nous avons les familles de serveurs contenant des GPU, donc la famille G2 et la famille P2, lancée fin d'année dernière. Avec des GPU disponibles 100% du temps, il y a une variante annoncée à ReInvent, les Elastic GPUs, qui est un service encore en preview, permettant d'attacher à la demande des GPUs sur des instances classiques, de la famille C, de la famille M, etc. Pour l'instant, c'est encore en preview. Nous avons aussi les instances optimisées pour les tailles de mémoire, donc R1, R3 et R4, même maintenant, qui sont des instances à très forte capacité mémoire, bien adaptées pour des applications in-memory, des applications Spark, et jusqu'à la famille X1, la plus énorme, avec X1, 32 XL, qui a presque 2 teraoctets de RAM, servant en particulier pour des applications SAP ou Spark très volumineuses. Le premier choix à faire est de déterminer le type d'exigence de votre application, le point potentiellement limitant : est-ce le stockage, le calcul, le GPU, la mémoire ? Cela vous guide vers un premier choix. Ensuite, vous pouvez tester plus finement à l'intérieur de ces familles. Lorsque vous regardez la description des instances et que vous essayez de jauger leur capacité de traitement, vous tombez rapidement sur la notion de VCPU (virtual CPU). Pour chaque instance, vous avez un nombre de VCPU qui quantifie sa puissance de traitement. Un VCPU n'est pas un cœur, contrairement à ce que beaucoup de gens pensent. C'est un hyper-thread d'un cœur. L'hyperthreading est une technologie d'Intel qui permet à un cœur de gérer deux hyperthreads, A et B, qui partagent les ressources du cœur pour augmenter le parallélisme de l'application. Quand vous avez le nombre de cœurs et que le CPU est hyper-threadé, vous multipliez par deux pour obtenir le nombre d'hyper-threads. Il y a une nuance entre Linux et Windows : sur Linux, ces hyper-threads sont numérotés de manière séquentielle, donc si vous avez huit hyper-threads (quatre cœurs avec huit hyper-threads), les threads A sont numérotés de 0 à 3 et les threads B de 4 à 7. Sur Windows, ils sont entrelacés : 0, 2, 4, 6 pour les hyper-threads A et 1, 3, 5, 7 pour les hyper-threads B. Un VCPU est donc un hyper-thread. Pour avoir le nombre de cœurs physiques, vous divisez le nombre de VCPU par deux. Si votre instance a quatre VCPU, elle a une puissance équivalente à deux cœurs physiques. Vous trouverez le décompte exact à l'URL indiquée ici. Il y a un white paper très intéressant qui explique cela en détail et donne des conseils supplémentaires pour bien choisir le bon nombre de VCPU pour vos charges de travail. Voici un exemple. C'est l'affichage d'un outil appelé LSTopo, qui donne la topologie physique des CPU et des cœurs d'une instance. Ici, c'est la configuration d'une instance M4 10X large. Elle a 20 cœurs, donc on voit les deux gros blocs, qui sont les deux CPU. Il y a le socket 0 et le socket 1, et chacun des sockets a 10 cœurs, de 0 à 9. Chaque cœur a deux hyperthreads. Au total, on a bien 40 hyperthreads. Ici, ils sont bien numérotés : 0, 1, 2, 3, 4, etc. Les A sont notés de 0 à 19, et les B de 20 à 39. C'est une machine Linux. Donc, un exemple simple : deux processeurs, 20 cœurs physiques et 40 hyperthreads. Dans certains cas, vous avez envie de désactiver l'hyperthreading. Pourquoi ? Cette notion d'accroissement de parallélisme peut perturber des applications qui ont besoin de calculer de manière brutale, de disposer du CPU pendant de longues périodes sans interruption. En particulier, des applications graphiques ou mathématiques qui prennent un certain temps et qu'on ne veut pas interrompre. On ne veut pas qu'un autre hyperthread vienne changer le contexte du cœur et interrompre l'application, ce qui crée de l'overhead et peut ralentir des charges de travail intensives. Pour désactiver l'hyper-threading sur Linux, vous pouvez utiliser LSTPU, qui vous donne le résultat, listant les numéros des cœurs. Vous voyez qu'ici on a quatre nœuds, 4 sockets, avec 64 cœurs. Les hyper-threads A sont numérotés de 0 à 63 et les hyper-threads B de 64 à 127. Sur Linux, on désactive les hyper-threads B. On peut le faire à chaud sur la machine avec un script qui met offline les hyper-threads numérotés de 64 à 127. On peut le faire à chaud, mais je vous conseille de le faire sur une instance au repos pour éviter des effets de bord. Si vous acceptez de redémarrer la machine, vous pouvez modifier le fichier de config de Grub avec max.cpu égale 63. Vous lui dites de se limiter aux hyperthreads numérotés de 0 à 63, et donc implicitement, on n'utilisera pas les hyperthreads B. Sur Linux, c'est relativement simple à faire. Si vous avez des applications intensives, faites le test. Vous verrez si ça tourne plus vite. Malheureusement, sur Windows, c'est plus compliqué puisque les identifiants de threads sont entrelacés. Il y a un mécanisme précis dans Windows appelé CPU Affinity qui permet de faire cette tâche de manière équivalente. Vous trouverez la procédure exacte dans la documentation de Microsoft. Une fois cette manipulation faite, toujours sur la même instance, on voit qu'on a mis offline les hyper-threads B et donc on n'a plus qu'un hyper-thread par cœur. Un thread applicatif qui tournerait sur un cœur disposerait intégralement de ce cœur, sans être perturbé par un hyperthread B qui créerait des changements de contexte et de l'overhead. Encore un petit rappel sur les tailles d'instances, ces fameuses tailles XL, 2XL, 8XL, etc. Les numéros ne sont pas choisis au hasard. Les rapports sont à peu près conformes. Une 8XL, c'est à peu près 2-4XL, et à peu près 4-2XL, et à peu près 8XL. Il peut y avoir des petites différences en fonction des familles, mais c'est à peu près l'ordre de grandeur. Lorsque vous faites des tests de performance, si vous trouvez qu'une instance est trop chargée ou au contraire trop peu chargée, en passant à la taille d'en dessous, vous pouvez vous attendre à diviser, ou en passant à la taille du dessus, à multiplier les performances à peu près par deux à chaque fois. Un autre point important est de comprendre que lorsque vous disposez de 4 VCPU, donc de deux cœurs, vous en disposez vraiment. Ces VCPU vous sont dédiés. Certes, on fait de la virtualisation, mais il n'y a pas de différence entre les ressources physiques et les ressources virtuelles. Si le calcul vous dit que vous avez quatre cœurs, vous avez quatre cœurs. Même pour la mémoire, la mémoire de votre instance est allouée, elle est à vous et personne d'autre ne l'utilise. Pour les ressources réseau, c'est pareil, lorsqu'on vous dit que vous avez X gigabits, vous avez réellement X gigabits. On partitionne vraiment notre réseau pour protéger les ressources allouées à une instance. Il n'y a pas d'over commitment. La somme des ressources utilisées par les VM est exactement la somme des ressources disponibles sur le serveur. La famille T est un peu différente, on en parlera plus tard. Mais vraiment, j'insiste sur ce point : lorsque vous avez X méga de Wix, XGo de RAM, XHucker et XGigabits, vous les avez, ils sont là et vous pouvez le tester, vous pouvez le benchmarker. Comment, une fois qu'on a dit tout ça, trouve-t-on la bonne taille d'instance ? Choisissez d'abord la bonne famille, puis une taille d'instance qui vous paraît raisonnable pour commencer. Installez votre application et faites des tests avec votre application. Nous vous conseillons vraiment de tester en grandeur nature. Les benchmarks synthétiques ne représentent jamais vraiment le profil de votre application. Faire du benchmark pur et dur sur l'Io, sur le réseau ou sur le CPU ne vous donnera pas une vision précise de la façon dont votre application fonctionne. Tester avec votre vraie application, passer vos tests unitaires, passer vos tests de charge et mesurer la réaction de votre application. En plus, cela vous montrera comment votre application scale, comment elle se comporte lorsque vous doublez le nombre de serveurs ou lorsque vous mettez un serveur deux fois plus gros. Le message est de tester avec l'application et de ne pas faire des benchmarks synthétiques qui ne vous apprendront pas grand-chose sur le monde réel. Passons au point suivant. Un point important pour les performances est la notion d'horloge. C'est quelque chose qu'on utilise fréquemment dans de nombreuses applications, en particulier les applications de base de données. Toutes les applications qui ont besoin de mettre des timestamps périodiquement font des appels systèmes comme GetTimeOfDay, etc. Il y a deux horloges disponibles sur les instances EC2. Il y a l'horloge de l'hyperviseur Xen, fournie par l'hyperviseur lui-même. L'avantage de cette horloge est qu'elle fonctionne sur toutes les instances EC2, quelle que soit la génération. Elle a l'avantage d'être standard. Le désavantage est qu'elle nécessite de traverser les couches de virtualisation via un appel système, via des changements de contexte, etc. Cela signifie que tous les appels systèmes liés à l'horloge sont relativement lents. Si vous utilisez peu la notion de temps dans votre application, ce n'est pas grave. Mais si vous utilisez une application, une base de données, etc., qui passe son temps à faire ce genre d'appel pour mettre des timestamps, vous pouvez avoir un impact de performance. Dans ce cas, nous vous conseillons plutôt d'utiliser la deuxième horloge, qui s'appelle le TSC, un registre processeur accessible en user space, donc dans l'espace d'adressage du processus qui fait l'appel. Il ne nécessite pas d'appel système, il ne nécessite pas de traverser les couches de virtualisation et il est beaucoup plus rapide. L'inconvénient est qu'il n'est disponible que sur des générations récentes de processeurs, à partir de Sandy Bridge, sorti en 2011-2012. Sur des instances de génération courante, il est forcément disponible. Nous vous conseillons donc fortement de configurer vos instances pour utiliser le TSC. Voici un petit benchmark simple. On fait un milliard d'appels à `getTimeOfDay`, en faisant un petit calcul mathématique pour que la fonction fasse quelque chose et que l'optimiseur n'enlève pas les appels. On mesure combien de temps on met à faire un milliard d'appels à `getTimeOfDay`. Si on le fait avec l'horloge Xen, ça prend 12 secondes. Si on fait un profilage de ce programme avec S-Trace, on voit que 99,99% du temps est passé à faire l'appel système `gettimeofday`. Le programme ne fait littéralement que gérer l'appel système `gettimeofday`. Si on utilise l'horloge TSC, le programme ne prend plus que deux secondes. Le coût de l'appel système a disparu et le bottleneck, le temps passé par le programme dans cet appel système, a complètement disparu. Il n'est même plus dans le top 10 des fonctions les plus coûteuses. Le message est que si vous avez une application qui fait énormément d'appels au temps pour des timestamps, utiliser le TSC peut vous apporter une amélioration de performance significative. Vous pouvez gagner quelques pourcents, peut-être même plus. La manipulation est plutôt facile. Pour consulter la liste des horloges disponibles, vous pouvez taper dans `/sys/devices/system/clocksource/clocksource0/available_clocksource`. L'horloge configurée ici est `Xen`. Pour la changer en route, vous faites simplement `echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource`. Cela suffit à changer l'horloge et à passer sur cette horloge rapide et accessible en user space dans vos processus. Sur les générations récentes de processeurs Intel, vous avez un mécanisme appelé Turbo Boost qui permet d'augmenter la fréquence d'horloge d'un cœur lorsque les autres cœurs ne sont pas utilisés. Vous pouvez monter jusqu'à 3,5 GHz de fréquence d'horloge sur les C4, par exemple. C'est très bien pour disposer d'une horloge encore plus rapide pendant des phases de calcul intensives. Si vous avez des tâches de travail peu parallélisées mais qui ont besoin d'une fréquence d'horloge maximale, c'est un bon mécanisme et il est activé par défaut. Le problème est que lorsque votre application devient plus parallèle et que vous avez besoin des autres cœurs, il faut un peu de temps pour réveiller les cœurs endormis, ce qui induit de la latence. Si vous alternez entre des phases de calcul intensives et des phases parallèles, vous perdez du temps à endormir et réveiller les cœurs. Pour certaines charges de travail, c'est gênant. Vous pouvez limiter l'impact des "C-state" avec une variable que vous configurez dans Grub. Cela limite le Turbo Boost, vous montez moins haut en fréquence, mais cela évite d'endormir des cœurs. Lorsque vous avez à nouveau besoin de ces cœurs, ils sont disponibles instantanément. Pour des applications où la latence est particulièrement importante, cette limitation est utile. Il y a un deuxième mécanisme obscur appelé "P-state". L'idée est de dire que lorsqu'un cœur utilise massivement les instructions AVX, qui sont des instructions de calcul vectoriel, on autorise la baisse en fréquence des cœurs moins actifs pour donner plus de puissance aux cœurs sollicités, pour rester à une enveloppe de consommation constante. Le problème est que cela induit de la latence pour remonter à la fréquence nominale des cœurs. Si vous voulez désactiver carrément le mode Turbo et faire en sorte que la fréquence de vos cœurs reste très stable et prévisible, vous pouvez désactiver les P-states avec cette commande. Ces mécanismes sont assez obscurs. Si vous en avez besoin, vous le savez probablement. Si ça ne vous parle pas du tout, c'est probablement que vous n'en avez pas besoin. Parlons maintenant des instances T2. Les instances T2 sont différentes. Elles ont un énorme avantage : elles sont les moins chères de toutes. La T2 Nano commence à 1,5 cent par heure. Elles ne disposent pas d'un VCPU complet, mais d'une fraction d'un VCPU. Le principal intérêt de ces instances est de ne pas être chères et de bien correspondre à des charges de travail épisodiques, appelées charges burstables. La plupart du temps, il ne se passe rien, puis pendant quelques minutes, vous avez besoin de puissance, puis plus du tout. Des charges de travail très irrégulières comme des petits serveurs web, des environnements de développement, des petites bases de données, des petits serveurs d'infra avec des charges extrêmement faibles. Si vous êtes prêt à faire ce compromis, vous pouvez bénéficier du prix très avantageux des instances T2. Nous avons différentes tailles : nano, micro, small, medium, large et xlarge, et maintenant deux xlarges. Ce qui les sépare, c'est ce qu'on appelle la baseline, c'est-à-dire quelle est la fraction de VCPU dont elles disposent. La T2 Nano, c'est vraiment tout petit, 5% d'un VCPU. Mais si 99% du temps, cette instance ne fait rien, c'est suffisant. Le fonctionnement de ces instances T2 est basé sur un système de crédits. Elles gagnent des crédits d'utilisation à chaque heure. Un crédit permet d'utiliser le cœur à pleine puissance pendant une minute. Par exemple, la T2 Micro a une baseline à 10%, donc 10% d'une heure, ce qui fait 6 minutes, et donc elle gagne 6 crédits par heure. Elle a le droit d'utiliser le VCPU à pleine puissance pendant 6 minutes. Après 6 minutes, elle est ralentie. Cette baseline augmente en fonction de la taille de l'instance. Un crédit, c'est l'accès pleine puissance pendant une minute. Vous les gagnez périodiquement, les crédits s'empilent jusqu'à expirer au bout de 24 heures. Lorsque vous utilisez l'instance, vous consommez les crédits. Vous pouvez burster pendant les minutes que les crédits que vous avez accumulés vous autorisent. C'est très différent des autres, mais très économique. Vous pouvez visualiser cette métrique dans CloudWatch, la balance des crédits de l'instance. Vous pouvez voir ici sur la courbe bleue combien de crédits dispose une instance. Lorsque l'activité CPU augmente, mécaniquement, les crédits diminuent. Et lorsque l'activité CPU cesse, les crédits se remettent à augmenter. Un conseil que je peux vous donner est que c'est une excellente métrique pour faire de l'autoscaling sur les T2. Si vous essayez de faire de l'autoscaling sur l'usage CPU des instances, ce n'est pas forcément une bonne chose parce que l'usage CPU est la conséquence des crédits. Si vous voulez autoscaler avec des T2, il vaut mieux regarder la balance et dire quand je n'ai plus de crédit, sur mon groupe d'autoscaling, je peux rajouter des instances pour avoir de nouveaux crédits. À l'autre extrémité du spectre, nous avons les X1, les instances les plus massives en termes de RAM, jusqu'à 2 Tera, comme je vous disais. Elles ont un nombre de VCPU extrêmement élevé, une quantité de stockage extrêmement élevée, des capacités réseau énormes. Elles sont un peu coûteuses, donc il faut les utiliser à bon escient. Elles sont vraiment dans le domaine des bases de données in-memory, du SAP, du gros travail, du gros JobSpark ou du HPC. L'architecture de ces serveurs est un peu différente. Cela nous amène à parler de NUMA. NUMA signifie Non Uniform Memory Access. Chaque processeur dispose d'une quantité de mémoire locale à laquelle il peut accéder très rapidement. Ces mémoires locales sont interconnectées avec un débit inférieur. Par exemple, sur la R3 8XL, nous avons deux processeurs avec 16 hyperthreads, 8 cœurs, et chaque processeur dispose de 122 GB de RAM. Une application qui tourne sur ce processeur et qui a besoin de RAM va plutôt aller piocher là-dedans. Si elle a besoin de davantage que 200 Go de RAM, elle en consommera ici et devra passer par ce bus d'interconnexion avec un temps d'accès supplémentaire. Mais ici, ce n'est pas trop gênant. Nous avons deux canaux d'interconnexion, et nous pouvons atteindre des débits très élevés. Lorsque nous allons sur des instances comme les X1, par exemple, nous avons quatre CPU avec 16 cœurs et 32 hyperthreads chacun. Chaque CPU a accès à environ 500 gigas de RAM. Il peut communiquer avec les autres pools de mémoire, mais il le fait ici avec un seul canal. L'impact de l'accès à la mémoire locale versus l'accès à la mémoire connectée à un autre processeur est plus fort. Il y a un mécanisme appelé Numa Balancing, qui existe dans Linux depuis un moment, sur Windows aussi, et qui permet de rapprocher les threads de la mémoire qu'ils utilisent. Si le noyau constate que des threads accèdent de manière répétée à une zone mémoire qui n'est pas sur le processeur local, il va bouger ces threads vers un autre processeur. On peut aussi bouger les zones de mémoire. Le noyau prend la bonne décision. C'est quelque chose qu'on peut avoir envie de désactiver. Si vous avez une application qui a besoin de 1 Tera de mémoire, par exemple, elle aura des threads qui tournent un peu partout et vous n'avez pas envie que les threads passent leur temps à se balader ou que la mémoire passe son temps à être copiée. Vous voulez que l'application s'exécute en place et éviter de perdre du temps à bouger des threads ou de la mémoire. Dans ce cas, il faut désactiver ce mécanisme de Numa balancing. Vous pouvez le faire dans Grub en mettant `numa=off`. C'est important, surtout sur les X1, où la taille des applications peut justifier ce genre d'optimisation. Un autre point important est l'impact de l'OS, de la fraîcheur ou de la non-fraîcheur de l'OS sur les performances de votre application. Par exemple, nous avons rencontré un cas client d'une application web très consommatrice de mémoire avec un grand nombre de threads, qui tournait sur Red Hat Enterprise Linux 6 et a été migrée vers AWS en Rails 6, où les performances étaient décevantes. L'équipe de Solution Architect a fait des tests et a comparé la performance de cette application entre RHEL 6 et RHEL 7 en utilisant des outils de simulation comme Ibizi et Perf. Lorsqu'ils ont testé Ibizi, un générateur de charge web, la simulation prenait à peu près 6 minutes sur Rails 6, et une grande partie du temps était passée dans le noyau. SIS, c'est le noyau, et User, c'est le process. La quasi-totalité du temps de cette charge de travail était passée dans l'OS. Le nombre de défauts de pages avait été divisé par presque 100, car le système d'exploitation plus récent optimise la gestion de la mémoire et n'a pas besoin de passer profondément dans les couches du noyau ou l'hyperviseur. La fraîcheur de votre OS a donc un impact énorme sur les performances de votre application, surtout dans des contextes de virtualisation. Un OS ancien n'a pas nécessairement évolué pour prendre en compte les dernières avancées des hyperviseurs et les utilise de manière naïve, ce qui peut entraîner des performances médiocres. Il est donc crucial d'utiliser des OS récents qui savent exploiter au mieux les capacités de la virtualisation des hyperviseurs et du cloud. Les huge pages sont un sujet important qui mériterait un webinaire à lui seul. En bref, les huge pages sont un mécanisme d'optimisation de la mémoire virtuelle qui augmente la taille des pages mémoire de 4K à 2 mégas, réduisant ainsi le nombre de pages à gérer par le noyau et libérant de la RAM pour les applications. Cependant, sur certains types d'applications, comme les bases de données, ce mécanisme peut être contre-productif, car l'initialisation de pages de 2 mégas prend beaucoup plus de temps que celle de pages de 4K. Les huge pages peuvent introduire de la latence sur des applications qui font beaucoup d'allocations et de libérations de pages. Des articles sur Oracle, PostgreSQL, etc., montrent que l'activation des huge pages peut nuire aux performances. Si vous voulez désactiver les huge pages, voici comment le faire. Si vous voulez les utiliser explicitement pour une application spécifique, voici comment le faire. Il existe de nombreux articles sur le sujet, et si vous n'avez pas ce problème, il est préférable de ne pas y toucher. En ce qui concerne les drivers, l'architecture classique entre le guest domain et le driver domain implique de traverser plusieurs couches, ce qui peut limiter les performances. Dans Linux 3.8 et au-dessus, un mécanisme optimisé appelé persistent grants pré-alloue des zones mémoire directement visibles dans l'espace d'adressage de l'application, permettant une communication plus directe avec les périphériques blocs et les disques. Pour vérifier que ce mécanisme est activé, vous pouvez utiliser la commande `dmesg | grep "Persistent Grants"` dans le log du noyau. Vous devriez voir "Persistent Grants Enabled". Il est important de noter que de nombreux systèmes utilisent encore des noyaux Linux extrêmement anciens, comme la version 2.6, datant de 2009. Migrer vers des noyaux plus récents, comme 3.10 ou 3.8, peut apporter un gain de performance significatif grâce aux optimisations de la virtualisation, des hyperviseurs, et du cloud. L'enhanced networking, qui est un accès direct à l'interface réseau physique, est un autre mécanisme similaire qui contourne les couches de virtualisation, offrant des performances proches du bare metal. Sur des instances récentes, ce mécanisme est probablement déjà activé, mais il est bon de le vérifier, surtout sur des instances plus anciennes. Les Elastic Network Adapters (ENA) permettent des débits réseau jusqu'à 20 gigabits au sein d'un même placement group, une configuration qui minimise la latence réseau. Sur des instances récentes, les ENA sont généralement déjà activés, mais il est toujours bon de vérifier. Le débit de 10 ou 20 gigabits est unidirectionnel entre deux instances dans le même placement group. Pour des instances moins puissantes, les niveaux de performance réseau varient entre high, moderate, et low, en fonction de la taille de l'instance. EBS Optimized est un autre facteur important de performance. Une instance EBS Optimized dispose d'une connexion réseau dédiée vers EBS, séparée du trafic normal. Si vous avez besoin de débits et de performances élevées sur votre stockage EBS, assurez-vous d'utiliser une instance EBS Optimized. Les instances non EBS Optimized mutualisent leur lien réseau entre le trafic de l'instance et le trafic EBS. En résumé, voici les points importants pour l'optimisation : - Utilisez des AMI en virtualisation hardware (HVM) pour les meilleures performances. - Utilisez l'horloge TSC pour les applications consommatrices de `gettimeofday`. - Modérez ou désactivez les C-State et P-State pour des applications nécessitant un temps de traitement constant. - Surveillez les CPU Credits pour les instances T2. - Utilisez un OS moderne, comme Amazon Linux, pour bénéficier des dernières optimisations. - Désactivez le Numa balancing pour les instances avec de grandes capacités de RAM. - Utilisez les persistent grants avec un noyau récent (3.8+). - Activez l'enhanced networking pour des performances proches du bare metal. - Testez votre application sur différentes tailles d'instances pour maîtriser vos coûts. - Profitez des EBS Optimized pour des performances de stockage élevées. Pour les questions : - Oui, le type d'instance a un impact sur les performances de stockage. Les familles I3 et D2 sont optimisées pour le stockage, avec des capacités élevées en termes de densité et d'IO. - Les AMI récentes sont en HVM, ce qui permet d'avoir l'enhanced networking, les ENA, et l'accès rapide au mode bloc. - La fraîcheur du noyau est plus importante que celle de la distribution, mais une distribution ancienne peut ne pas supporter les derniers noyaux. - Les instances X132 XL disposent de 488 GB de mémoire, un chiffre bizarre qui pourrait être dû à l'utilisation de la mémoire par le système ou le cloud. - PHP 7 a un impact positif sur les performances, tout comme les bonnes versions de vos frameworks. - EC2 offre les mêmes performances pour une même catégorie d'instances dans toutes les régions. - Pour une application de cache mémoire, testez entre une instance R et une instance C, en fonction de vos besoins en termes de capacité et de latence. - La surallocation est une mauvaise pratique, car elle peut entraîner des performances médiocres lorsque tous les utilisateurs consomment la ressource en même temps. - AWS investit beaucoup dans les énergies vertes, avec des fermes d'éoliennes et solaires produisant près de 1 gigawatt d'énergie verte, et 40% de l'énergie consommée par les data centers AWS est verte. - Les spécifications des instances EC2 ne changent pas dans le temps. Il y a des vieilles familles d'instances qui tournent encore parce qu'on a des clients qui s'en servent et on ne veut pas les forcer à migrer. Donc non, on garde stable dans le temps ces performances. Et est-ce que les prix augmentent ? Non, les prix n'augmentent pas. Les prix ont plutôt tendance à baisser. On a annoncé en fin d'année dernière une baisse de 5% sur tout EC2. Voilà, 21 novembre 2021, on a annoncé une baisse importante, je crois que c'était 5%, si je ne m'abuse. On a baissé le prix de tout EC2 de 5% d'un coup. Et on en est pratiquement maintenant à une soixantaine. Depuis le lancement d'AWS, on en est quasiment à une soixantaine de baisse de prix. Sur tous les services, soixantaine de baisse de prix depuis 10 ans. Donc à chaque fois qu'on peut baisser les prix, on le fait parce que c'est important pour nos clients. Donc non, il n'y a pas de hausse de prix sur AWS. Alexandra précise, la surallocation de notre fournisseur actuel nous a poussé à le quitter pour aller vers AWS. Écoutez, je ne peux que vous remercier de l'avoir fait. J'espère que ça marche mieux maintenant. Merci de ce feedback. Une dernière question. Il y a une question de Grégoire sur tout ce que tu dis sur Linux, pas avoir des Linux trop vieux, c'est aussi valable pour Windows. Oui, c'est sûr. Alors, est-ce que j'ai des recommandations à faire sur Windows. Je vais être très, très honnête avec vous. Je connais assez mal les environnements Microsoft et Windows, donc je ne peux pas vraiment répondre à cette question. On va la noter pour mon collègue Julien Lépine, qui est un solution architecte spécialiste des solutions Microsoft et qui animera le mois prochain, sauf erreur de ma part, un webinar sur SQL Server. Donc, on note la question, on lui posera, mais honnêtement, j'avoue mon incompétence sur ce sujet, je préfère ne pas vous dire d'ânerie. Je pense qu'on a répondu à presque toutes les questions. Il en reste encore quelques-unes, je suis désolé, on n'a plus de temps, il faut choisir encore un gagnant. Eh bien, on va faire gagner Alexandra, parce qu'elle a été gentille. Merci Alexandra. Et tous les autres sont fâchés, ils me détestent. Et puis, il était temps qu'on fasse gagner une fille, quand même. On fait gagner que des mecs. Après, on va dire que t'es sexy, vive les filles dans l'informatique et vive les filles dans l'admin système. Il en faut plus. Qu'est-ce qu'on a à dire, Hugo ? On a fait le tour de la question ? Je pense qu'on a fait le tour de la question. Merci encore de votre écoute et de votre fidélité. On est vraiment content d'avoir toujours autant de monde sur ces webinaires. Salut aux francophones, aux amis canadiens, africains, belges, suisses, j'en oublie sûrement. Signalez-vous, envoyez un truc à Hugo dans le chat, c'est toujours sympa de savoir que des gens nous écoutent dans des pays lointains, ça nous fait plaisir. J'espère pouvoir venir vous voir bientôt. Je vous rappelle le Summit à Paris le 27 juin, les inscriptions sont ouvertes, vous trouverez la page d'inscription sur notre site. Et puis voilà, une dernière fois, si vous êtes content de ces webinars, s'il vous plait, faites-nous un petit coucou aussi sur Twitter, aws underscore actu, ou un petit coucou sur mon Twitter, Jules Simon, que je vous ai déjà montré plein de fois. Ça nous fait toujours plaisir de voir ça, et puis de voir qui vous êtes aussi. Et puis, voilà. Faites du bruit, invitez vos amis, invitez vos collègues. Plus on sera nombreux dans les user group, plus on sera nombreux dans les meet-up, plus on sera nombreux dans les webinars, plus on aura de moyens aussi pour organiser des événements et répondre encore mieux à vos attentes et à vos questions. Tout ça, c'est pour vous et on est vraiment content de le faire et on veut en faire encore plus. Plus vous serez nombreux et plus on aura les moyens d'organiser des trucs sympas. Je vous souhaite une bonne fin de journée, une bonne soirée, et donc rendez-vous le mois prochain pour une nouvelle série de webinaires sur les bases de données. Ça promet. Merci beaucoup. Très bien, à très bientôt, et bonne soirée.