Kernel on Zwindler's Reflection

Optimisation de PFsense dans Proxmox VE

Mon, 06 Jul 2020 06:40:00 +0000

PFsense + Proxmox VE = <3

Si vous suivez ce blog, vous savez que je parle régulièrement de Proxmox VE. En particulier, j’ai travaillé avec 2 autres personnes (M4vr0x et Charles BORDET pour écrire 2 suites de plusieurs articles sur Proxmox et PFsense.

Dans ces deux suites d’articles, à chaque fois l’angle était le même. Débuter avec Proxmox en montant, de 0, un serveur Proxmox VE, mais sans non plus prendre trop de risques et en le sécurisant un maximum avant d’installer quoique ce soit dessus.

Proxmox VE 6 + pfsense sur un serveur dédié (1/2)

Sauf que, dans les deux cas, j’ai trouvé que les perfs des machines virtuelles avec PFsense étaient assez… molles.

Heureusement, après quelques années de déterrage de posts sur les forums de Proxmox VE, on finit par chopper des tips and tricks que je vous partage aujourd’hui.

Sur les vielles versions de Proxmox VE

La première chose qui m’a gêné lorsque j’ai déployé la consommation CPU de PFsense alors que je n’avais encore rien commencé à faire avec.

Autour de 7-8% en idle, alors que je ne lui envoie pour l’instant aucun trafic. Juste faire tourner l’OS dans le vide.

Pour ceux qui ne le savent pas, PFSense est un firewall basé sur l’OS FreeBSD. J’ai donc commencé à chercher des tips pour améliorer les perfs des VMs sous FreeBSD dans KVM.

Je suis tombé là dessus.

Sur les plus vieux Proxmox (<6 en tout cas), un gain significatif en terme de CPU peut être trouvé en modifiant 2 paramètres dans le fichier /boot/loader.conf`

hint.apic.0.clock=0
kern.hz=100

Là où la manœuvre est un peu “tricky” comme on peut dire, c’est que normalement, si vous êtes comme moi, même en ayant paramétré lors de l’installation le clavier Azerty, dans la console PFsense, vous allez être en Qwerty… Bref, avec un layout de clavier qwerty sous les yeux vous devriez vous en sortir (des consoles KVM, iLO, iDRAC qui déconnent, j’ai l’habitude au bout de 10 ans), mais la vraie solution est de corriger le layout de la façon suivante :

cd /usr/share/syscons/keymaps
kbdcontrol -l fr.iso.kbd
#ou en qwerty virtue sur votre clavier azerty physique
cd !usr!shqre!syscons!key,qps
kbdcontrol )l fr:iso

YOUHOU ! Enfin en azerty dans cette fichue console !

Après reboot`, effectivement, sur un vieux Proxmox, j’ai gagné entre 3 et 4%. Pour d’autres personnes, les gains étaient bien plus significatifs, car ça dépend du CPU a priori.

En revanche, sur mon Proxmox VE 6, pas de gain. C’est même le contraire, je suis passé de 2,5% en moyenne à 4% ! Argh…

Deuxième optim, qui marche presque à tous les coups

Là par contre, celle ci à de la valeur même sur PVE6. Proxmox VE ajoute systématiquement sur les VMs une option : “Use tablet for pointer”.

Je n’ai pas trouvé beaucoup de documentation à ce sujet, il semblerait que cela serve à améliorer la précision du pointeur de la souris dans la console. Autant dire que pour PFsense, on s’en cogne !

Dans le menu de la VM, dans Options, cherchez Use tablet for pointer puis désactivez l’option :

Vous devriez avoir ce message qui s’affiche dans la console

Et là, les gains sont significatifs ! On passe de 2,5% à moins de 1%.

Ce qui est cool avec cette tips, c’est que ce conseil vaut aussi pour toutes les VMs que vous utilisez sans environnement graphique (et ça vaut aussi le coup de tester pour les envs graphiques).

Voilà ce que ça donne sur un serveur Ubuntu 18.04 avec environnement graphique, qui fonctionne aussi bien avant qu’après.

Encore plus significatif !

VirtIO

Depuis FreeBSD 9, les pilotes pour le matériel virtuel de type VirtIO sont directement intégrés. L’avantage de VirtIO par rapport à du matériel virtuel classique c’est que les pilotes sont “paravirtualisés”. Un gros mot pour dire que le pilote est “au courant” qu’il s’agit de matériel virtuel, permettant de bien meilleure performance.

On a de la chance, la dernière version de PFsense (la 2.4.5) est basée sur FreeBSD 11 :-)

Si vous avez le choix donc, c’est VirtIO en priorité !

Hardware offloading, c’est non !

Maintenant que j’ai dis ça… il faut quand même que je vous parle du pilote réseau VirtIO avec PFsense.

Si jamais vous l’installez tel quel et que vous ne faites rien de plus, vous allez avoir des surprises… Perfs pourries, NAT impossible, etc…

En fait, il est nécessaire de cocher plusieurs cases dans l’interface de PFsense.

Dans System / Advanced / Networking, il faut cocher les cases suivantes :

Hardware TCP Segmentation Offloading
Hardware Large Receive Offloading

Et tout de suite, ça ira beaucoup mieux :)

Sources et documentations

Transparent Hugepages : mesurer l’impact sur les performances

Mon, 24 Feb 2020 07:30:00 +0000

Encore les Transparent Hugepages ?

Il y a quelques jours, j’ai posté un article pour vous aider à désactiver les Transparent Hugepages.

A là suite de ça, Seboss666 (qui tient un super blog bien Geek/sysadmin comme j’aime) m’a fait remarquer en commentaire que j’expliquais surtout comment désactiver les THP. Mais je n’ai pas beaucoup parlé d’à quoi ça sert (à part que c’est mal aimé, comme SELinux) et si ça a vraiment un impact sur les perfs.

Il m’a passé un article hyper intéressant, en anglais, sur le sujet. Comme je ne l’aurais pas mieux écris moi-même ET que le but du blog est d’être une ressource francophone, j’ai donc proposé à l’auteur, Alexandr Nikitin, de le traduire en français. Le voilà donc.

Introduction

TL;DR ce post a pour but d’expliquer en un mot ce que sont les Transparent Hugepages (THP), décrire les techniques qui seront utilisées pour mesurer leur impact sur les performances et enfin, montrer leur effet sur une application réelle.

Il est inspiré par un thread a propos des Transparent Huge Pages sur le “Mechanical Sympathy group”. Ce thread expose les pièges, les problématiques de performances ainsi que l’état actuel dans les dernières versions du kernel. Une grosse quantité d’information peut y être trouvé.

En général, vous allez trouver beaucoup de recommendations sur Internet à propos des Transparent Hugepages. La plupart d’entre eux vous diront de désactiver totalement les THP, comme Oracle Database (lien mort), MongoDB, Couchbase (lien mort, j’utilise Internet Archive), MemSQL (lien mort), NuoDB. Certains logiciels utilise la fonctionnalité, comme par exemple PostgreSQL (la fonctionnalité hugetlbpage, pas exactement les THP) et Vertica. Il existe beaucoup de retours d’expériences de professionnels qui ont eu à se battre contre des freeze de leur système et l’ont “corrigé” simplement en désactivant les THP. 1, 2, 3 (lien mort, j’utilise Internet Archive), 4, 5, 6. Toutes ces histoires tendent à propager une vision faussée et le préjugé que cette fonctionnalité est dangereuse.

Malheureusement, je n’ai pas trouvé de post qui mesure ou montre comment mesurer l’impact et les conséquences d’activer ou de désactiver cette fonctionnalité. C’est ce que ce post va tenter de répondre.

Les Transparent Hugepages en bref (presque)

Pour fonctionner, presque toutes les applications et les systèmes d’exploitation nécessitent de la mémoire “virtuelle”. La mémoire virtuelle de tous les logiciels est ensuite mappée dans la mémoire physique. Ce mapping est géré par le système d’exploitation, qui maintient une structure de donnée en RAM (page table). Pour passer de l’adresse virtuelle à l’adresse physique (page table walking), on utilise un composant du CPU (la MMU). En plus de servir de table de traduction, la MMU sert également de cache des pages récemment utilisées. On appelle ce cache le Translation lookaside buffer (TLB).

Lorsqu’une adresse virtuelle doit être traduite dans une adresse physique, on cherche d’abord dans le TLB. Si un résultat est trouvé (TLB hit), l’adresse physique est retournée et l’accès à la mémoire peut continuer. Cependant, si on ne trouve pas de résultat (TLB miss), la MMU va devoir rechercher le mapping de l’adresse dans la table de pages (page table) si il existe.

Ce processus de “page table walk” est coûteux en temps car il peut nécessiter plusieurs accès à la mémoire (cependant, avec de la chance on peut retrouver la page mémoire dans un des caches L1/L2/L3 du CPU). Cependant, on ne peut pas non plus compter tout le temps sur le TLB car sa taille est limitée (généralement quelques centaines de pages, au maximum).

Les systèmes d’exploitation gèrent la mémoire virtuelle en utilisant des pages (des blocks contigus de mémoire). Généralement, la taille d’une page mémoire est de 4 Ko. Petite règle de trois, 1 Go de RAM équivaut à 256000 pages, et 128 Go à 32,7 millions de pages. Clairement, on ne va pas pouvoir tout stocker dans le TLB et nous allons donc souffrir de problèmes de performances à cause des “TLB miss”. Il y a deux façons d’améliorer cette situation. La première est d’augmenter la taille du TLB. Cependant, c’est coûteux et l’impact n’est pas significatif, surtout sur les systèmes disposant d’une très grande quantité de RAM. La seconde consiste à augmenter la taille d’une page est ainsi, avoir moins de pages à mapper. Les OS et les CPUs modernes sont typiquement capable de supporter des pages “larges” de 2 Mo, voire même de 1 Go. Ainsi, avec des pages de 2 Mo, 128 Go de RAM devient seulement 64000 pages.

Ce n’est pas pour rien que Linux supporte les Transparent Hugepages. C’est une optimisation ! Cela permet de gérer un grand nombre de pages de manière automatique et transparente pour les applications. Les bénéfices sont évidents : pas de modification à faire du coté des application, le nombre de “TLB miss” est réduit, le “page table walking” devient moins coûteux. Cette fonctionnalité peut être découpée en deux parties : allocation et maintenance.

Le THP fonctionne de la même manière pour ce qui est de l’allocation de la mémoire et nécessite que le système d’exploitation trouve des blocs alignés et contigus de mémoire. Dans ce cas précis, il souffre également des mêmes problèmes que les pages de mémoire classiques, à savoir la fragmentation. Si l’OS ne sait pas trouver de blocs de mémoire continus, il va essayer de “compacter”, réclamer les partions inutilisées ou “page out” les autres pages. Ce processus est couteux et peut provoquer de grosses latences (jusqu’à quelques secondes). Heureusement, ce problème a été adressé dans la version 4.6 du kernel Linux (avec l’option defer) ; l’OS retourne dans le mode classique (page de 4K) si jamais il ne trouve pas de place pour une hugepage.

La deuxième partie est la maintenance. Si une application ne modifie ne serait ce qu’un seul octet de mémoire, elle va consommer la taille d’une page entière, à savoir 2 Mo si on utilise des hugepages, ce qui est clairement un gaspillage de mémoire vive. Pour palier à ça, il existe une tâche de fond qui s’appelle khugepaged. Ce processus scanne les pages et essaye de défragmenter et concaténer toutes les pages presque vides dans une seule page. Cependant, même si c’est une tâche de fond, elle va bloquer les pages sur lesquelles elle fonctionne, ce qui peut aussi provoquer des pic de latence. Un dernier problème reste qu’il est parfois nécessaire de découper les grosses pages, car tous les composants de l’OS ne supportent pas les hugepages. C’est le cas de la swap par exemple. L’OS doit alors découper les grosses pages en plus petites pour ces composants là. Encore une fois, cette opération peut dans certain cas dégrader les performances et augmenter la fragmentation.

Le meilleur endroit pour apprendre comment fonctionnent les Transparent Hugepage est évidemment la documentation officielle du Kernel Linux. Cette fonctionnalité dispose de plusieurs éléments de configuration ainsi que des flags pour modifier son comportement. Ils évoluent avec le Kernel lui même.

Comment le mesurer ?

C’est probablement la partie la plus importante de ce post. Basiquement, il y a deux façon de mesurer l’impact de cette fonctionnalité : les CPU counters et les kernel functions.

CPU counters

Commençons par les CPU counters. J’utilise perf, qui est un outil génial et simple pour réaliser ce genre de mesures. Perf dispose nativement d’alias pour les événements du TLB : dTLB-loads, dTLB-load-misses pour les hit et les miss en load; dTLB-stores, dTLB-store-misses (idem mais pour les stores).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses -a -I 1000
# time counts unit events
1.006223197 85,144,535 dTLB-loads
1.006223197 1,153,457 dTLB-load-misses # 1.35% of all dTLB cache hits
1.006223197 153,092,544 dTLB-stores
1.006223197 213,524 dTLB-store-misses
...

Et la même chose pour les instructions (iTLB-load, iTLB-load-misses).

[~]# perf stat -e iTLB-load,iTLB-load-misses -a -I 1000
# time counts unit events
1.005591635 5,496 iTLB-load
1.005591635 18,799 iTLB-load-misses # 342.05% of all iTLB cache hits
...

En réalité, perf supporte seulement un petit sous ensemble de tous les événements alors que les CPUs ont des centaines de compteurs pour évaluer la performance. Pour les CPUs Intels par exemple, on peut trouver la liste de tous les compteurs disponibles sur le site Intel Processor Event Reference, dans le Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 3B ou bien encore dans les sources du Kernel Linux. Le manuel du développeur contient également des codes d’événements que nous devons passer pour analyser les performances.

Si on regarde les compteurs relatifs au TLB, voilà ce qu’on peut trouver d’intéressant :

Mnemonic	Description	Event Num.	Umask Value
DTLB_LOAD_MISSES.MISS_CAUSES_A_WALK	Misses in all TLB levels that cause a page walk of any page size.	08H	01H
DTLB_STORE_MISSES.MISS_CAUSES_A_WALK	Miss in all TLB levels causes a page walk of any page size.	49H	01H
DTLB_LOAD_MISSES.WALK_DURATION	This event counts cycles when the page miss handler (PMH) is servicing page walks caused by DTLB load misses.	08H	10H
ITLB_MISSES.MISS_CAUSES_A_WALK	Misses in ITLB that causes a page walk of any page size.	85H	01H
ITLB_MISSES.WALK_DURATION	This event counts cycles when the page miss handler (PMH) is servicing page walks caused by ITLB misses.	85H	10H
PAGE_WALKER_LOADS.DTLB_MEMORY	Number of DTLB page walker loads from memory.	BCH	18H
PAGE_WALKER_LOADS.ITLB_MEMORY	Number of ITLB page walker loads from memory.	BCH	28H

Perf supporte le compteur *MISS_CAUSES_A_WALK via un alias. Mais nous devrons trouver l’identifiant numérique des autres événements pour les passer en arguments. Point important, les numéros d’événements et les valeurs umask associées dépendent de chaque CPU. Par exemple, la liste ci dessus est spécifique à l’architecture Intel Haswell ! Il vous sera nécessaire d’adapter ces codes à votre CPU.

Une des métriques clé est le nombre de cycle CPU passés à faire du page table walking :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
1.005079845 227,119,840 cycles
1.005079845 2,605,237 dcycles
1.005079845 806,076 icycles
...

Une autre métrique importante est le nombre de lecture mémoire qui causent des TLB miss ; ces lectures ne profitent pas du cache CPU et sont donc coûteuses :

[~]# perf stat -e cache-misses \
> -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
1.007177568 25,322 cache-misses
1.007177568 23 dreads
1.007177568 5 ireads
...

Kernel functions

Une autre façon surpuissante de mesurer l’impact des THP sur les performances et la latence est d’utiliser les fonctions de tracing/probing du Kernel Linux. J’utilise SystemTap pour ça, qui est un outil pour instrumenter dynamiquement les systèmes Linux en production.

La première fonction intéressante pour le cas qui nous intéresse est __alloc_pages_slowpath. Elle est exécutée lorsqu’il n’y a pas de bloc contigu de mémoire vive disponible lors d’une allocation. A son tour, cette fonction appelle la fonction de “récupération” et de “compaction” des pages, qui je le rappelle est une opération très couteuse qui peut engendrer des pics de latence.

La seconde fonction intéressante est khugepaged_scan_mm_slot. Elle est exécutée en tâche de fond par le thread khugepaged du Kernel. Ce thread scanne les hugepages et essaye de les compacter en une seule.

J’utilise un script SystemTap pour mesurer le temps d’exécution d’une fonction. Ce script stocke tous les temps d’exécution en microsecondes et affiche périodiquement un histogramme. Il ne consomme que quelques Mo par heure, en fonction du nombre d’exécutions. Le premier argument est la sonde à utiliser, le second est un nombre (en ms) pour afficher les statistiques.

#! /usr/bin/env stap
global start, intervals
probe $1 { start[tid()] = gettimeofday_us() }
probe $1.return
{
t = gettimeofday_us()
old_t = start[tid()]
if (old_t) intervals <<< t - old_t
delete start[tid()]
}
probe timer.ms($2)
{
if (@count(intervals) > 0)
{
printf("%-25s:\n min:%dus avg:%dus max:%dus count:%d \n", tz_ctime(gettimeofday_s()),
@min(intervals), @avg(intervals), @max(intervals), @count(intervals))
print(@hist_log(intervals));
}
}

Voici un exemple avec la fonction __alloc_pages_slowpath :

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 1000
Thu Aug 17 09:37:19 2017 CEST:
min:0us avg:1us max:23us count:1538
value |-------------------------------------------------- count
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 549
1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 541
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 377
4 |@@@@ 54
8 |@ 12
16 | 5
32 | 0
64 | 0
...

Il est également intéressant de savoir observer l’état général de l’OS. Un bon exemple peut être la fragmentation de la mémoire. /proc/buddyinfo est un outil utilise pour aider au diagnostic dans ce genre de cas. Buddyinfo va nous donner des pistes pour estimer la taille maximale que l’on peut allouer sans risque, ou pourquoi la précédent allocation a échoué par exemple. De même, on peut aussi trouver des informations utiles dans /proc/pagetypeinfo.

cat /proc/buddyinfo
cat /proc/pagetypeinfo

Vous pouvez en apprendre plus en lisant la documentation officielle (lien mort, j’utilise Internet Archive) ou alors en lisant cet article.

JVM

La JVM supporte les Transparent Hugepages via l’ajout de l’option -XX:+UseTransparentHugePages. Cependant, on aura alors un message d’avertissement contre de possibles problèmes de performance :

-XX:+UseTransparentHugePages On Linux, enables the use of large pages that can dynamically grow or shrink. This option is disabled by default. You may encounter performance problems with transparent huge pages as the OS moves other pages around to create huge pages; this option is made available for experimentation.

Il est intéressant d’activer l’usage des large pages pour le “Metaspace” :

-XX:+UseLargePagesInMetaspace Use large page memory in metaspace. Only used if UseLargePages is enabled.

De plus, utiliser l’option -XX:+AlwaysPreTouch avec les hugepages peut être une bonne idée. Cela permet de réallouer toute la mémoire physique utilisé par le tas (heap) et ainsi éviter une surcharge supplémentaire due à l’initialisation ou à la compaction. Cependant, cela induira une augmentation du temps nécessaire pour initialiser la JVM.

-XX:+AlwaysPreTouch Enables touching of every page on the Java heap during JVM initialization. This gets all pages into the memory before entering the main() method. The option can be used in testing to simulate a long-running system with all virtual memory mapped to physical memory. By default, this option is disabled and all pages are committed as JVM heap space fills.

Aleksey Shipilёv montre l’impact sur la performance dans son article de post JVM Anatomy Park #2: Transparent Huge Pages.

Un exemple de la vie réelle : une JVM très chargée

Regardons maintenant quel impact ont réellement les Transparent Hugepages sur une application réelle. Prenons une application lancée dans une JVM : un serveur TCP basé sur netty et recevant un trafic important. Le serveur reçoit jusqu’à 100k requêtes par secondes, analyse chaque requête, effectue un appel réseau à une base de données pour chacun des appels, fait un certain nombre de calculs dessus, puis retourne un réponse. L’application en question possède une heapsize de 200 Go. Les mesures ont été réalisées sur des serveurs de production, ainsi que la charge réelle de production. Les serveurs n’étaient pas surchargés et recevaient 50% du nombre maximal de requêtes qu’ils étaient capables de traiter.

Transparent Hugepages désactivées

Désactivons les THP :

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

La première chose à faire et de mesurer les TLB misses. Ici on a environ 130 millions de TLB misses. Le ratio Miss/Hit est de 1% (ce qui ne semble pas énorme, au premier abord).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
# time counts unit events
...
10.007352573 9,426,212,726 dTLB-loads
10.007352573 99,328,930 dTLB-load-misses # 1.04% of all dTLB cache hits
10.007352573 26,021,651 iTLB-load-misses
10.007352573 10,955,696 dTLB-store-misses
...

Cependant, regardons plus précisément combien nous ont coûté en temps CPU ces TLB misses :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
...
12.007998332 61,912,076,685 cycles
12.007998332 5,615,887,228 dcycles
12.007998332 1,049,159,484 icycles
...

Oui, vous avez bien vu ! Plus de 10% des cycles CPUs sont utilisés pour parcourir la page table.

Le compteur suivant montre que nous avons 1 million de lectures RAM causées par des TLB misses (sachant que chacunes de ces lectures coûtent 100 ns chacunes) :

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
...
6.003683030 1,087,179 dreads
6.003683030 100,180 ireads
...

Tous les nombres que je viens de vous montrer sont intéressants, mais ils ne sont pas vraiment “exploitables”. Les métriques les plus importantes pour un développeur d’application sont les métriques de l’application elle-même. Regardons donc comment la métrique de la latence end-to-end de l’application. Voilà les mesures (en microsecondes) qui ont été récoltées pendant quelques minutes :

"max" : 16414.672,
"mean" : 1173.2799067016406,
"min" : 52.112,
"p50" : 696.885,
"p75" : 1353.116,
"p95" : 3769.844,
"p98" : 5453.675,
"p99" : 6857.375,

Transparent Hugepages activées

Maintenant on va pouvoir commencer à faire des comparaisons ! Activons les THP :

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag # consider other options too

Et lançons la JVM avec les options -XX:+UseTransparentHugePages, -XX:+UseLargePagesInMetaspace et -XX:+AlwaysPreTouch.

La première métrique que nous avions collecté (les TLB misses) ont été divisés par 6, passant de 130 millions à environ 20 millions. Mathématiquement, le ratio miss/hit tombe de 1% à 0,15%. Voici les nombres exacts :

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
# time counts unit events
1.002351984 10,757,473,962 dTLB-loads
1.002351984 15,743,582 dTLB-load-misses # 0.15% of all dTLB cache hits
1.002351984 4,208,453 iTLB-load-misses
1.002351984 1,235,060 dTLB-store-misses

Les cycles CPU passés à parcourir la page table ont également diminué d’un facteur 5, d’environ 6,7 milliards à 1,3 milliards. Cette fois ci, nous avons donc utilisé seulement 2% de notre CPU à réaliser du “page table walking” :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
...
8.006641482 55,401,975,112 cycles
8.006641482 1,133,196,162 dcycles
8.006641482 167,646,297 icycles
...

Et enfin, le nombre de lecture en RAM a diminué de 1 million à 350k

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
...
12.007351895 342,228 dreads
12.007351895 17,242 ireads
...

Tout ça c’est bien beau, mais, une fois encore, les nombres qui vont le plus nous intéresser, c’est l’effet réel que ça va avoir sur notre application. Voici les chiffres de la latence end-to-end de l’application :

"max" : 16028.281,
"mean" : 946.232869010599,
"min" : 41.977000000000004,
"p50" : 589.297,
"p75" : 1080.305,
"p95" : 2966.102,
"p98" : 4288.5830000000005,
"p99" : 5918.753,

La différence entre les deux runs sur les 95 percentiles est quasiment de 1 milliseconde ! Voici ce que cela représente visuellement :

Source : https://alexandrnikitin.github.io/blog/images/transparent-hugepages-measuring-the-performance-impact/grafana.png

Nous venons donc de mesurer l’amélioration apportée par l’activation des Transparent Hugepages. Cependant, nous savons que l’activation des THP peut avoir un impact sur les performances (à cause de l’overhead de la “maintenance” que nous avons expliqué plus haut) ainsi que les risques de pic de latence. Nous devons donc également les mesurer. Regardons le thread kernel khugepaged qui s’occupe de la défragmentation des hugepages. La mesure qui suit a été réalisée sur une durée d’environ 24 heures. Comme vous pouvez le constater, le temps maximum d’exécution est de 6 millisecondes et il y a de nombreuses exécutions qui ont pris moins d’une milliseconde. Si ce processus est en tâche de fond, mais il bloque les pages concernées pendant qu’il travaille dessus. Voici l’histogramme :

[~]# ./func_time_stats.stp 'kernel.function("khugepaged_scan_mm_slot")' 60000 -o khugepaged_scan_mm_slot.log
[~]# tail khugepaged_scan_mm_slot.log
Thu Aug 17 13:38:59 2017 CEST:
min:0us avg:321us max:6382us count:10834
value |-------------------------------------------------- count
0 |@ 164
1 |@ 197
2 |@@@ 466
4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 6074
8 |@@@@@@ 761
16 |@@ 318
32 | 65
64 | 13
128 | 1
256 | 3
512 |@@@ 463
1024 |@@@@@@@@@@@@@@@@@@ 2211
2048 | 85
4096 | 13
8192 | 0
16384 | 0

Une autre fonction important du kernel est __aloc_pages_slowpath. Cette fonction aussi peut provoquer des pics de latence si un block contigue de mémoire n’est pas disponible. Lors de la mesure, l’histogramme est bien meilleur ici. Le temps maximum d’allocation était de 288 microsecondes. Même en le faisant tourner pendant des heures voire même des jours, nous sommes devenus confiant dans le fait que cette fonctionnalité n’allait pas provoquer de longs pics de latence.

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 60000 -o alloc_pages_slowpath.log
[~]# tail alloc_pages_slowpath.log
Tue Aug 15 10:35:03 2017 CEST:
min:0us avg:2us max:288us count:6262185
value |-------------------------------------------------- count
0 |@@@@ 237360
1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2308083
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2484688
4 |@@@@@@@@@@@@@@@@@@@@@@ 1136503
8 |@ 72701
16 | 22353
32 | 381
64 | 7
128 | 105
256 | 4
512 | 0
1024 | 0

Alors comment se fait il que les Transparents Hugepages fonctionnent aussi bien dans ce cas précis ? D’abord, on remarque un amélioration significative de la performance car dans ce cas précis on travaille avec une grande quantité de RAM. De même, on ne remarque pas de pics de latences car il n’y a pas de surcharge en terme de RAM sur le serveur. Il y a beaucoup de RAM (256 Go), la JVM sait tirer partie des THP, pré-alloue la totalité des 200 Go de heap dès le démarrage et ne la redimensionne jamais.

Conclusion

Ne suivez pas aveuglément les recommandation que vous trouvez sur Internet ! Mesurez, mesurez, mesurez encore !

Les Transparent Hugepages sont une optimisation et qui peut avoir de réelles conséquences positives sur la performance, mais avec des inconvénients et des risques qui peuvent entrainer des conséquences imprévues. Le but de ce post était de donner les clés pour mesurer les gains potentiels et gérer les risques. Le Kernel Linux et ces fonctionnalités évoluent et certains des problèmes des THP ont été adressés dans les dernières versions, comme par exemple l’option “defer” de la défragmentation, qui permet à l’OS de repasser sur une allocation de taille normale, si jamais il n’est pas possible d’en allouer une large.

Note de zwindler : Encore merci à l’auteur (Alexandr Nikitin) pour son article, qui m’a appris beaucoup de choses !

Bug : unable to execute QEMU command ‘cont’ sous KVM et RHEL/CentOS

Sat, 10 Oct 2015 10:30:00 +0000

Cet article est encore un vieil article que je n’ai jamais pris le temps de sortir. Voilà maintenant c’est fait ;-)

Bug unable to execute QEMU command ‘cont’

Aussi rare que cela soit, après ma migration de KVM sur Ubuntu a KVM sur CentOS, je suis tombé sur un bug du Kernel Linux qui affectait directement ma capacité à faire fonctionner des machines virtuelles sous Windows 7 ou Windows 2008 ! Mais toutes les autres fonctionnaient normalement.

Symptôme

Lorsqu’on démarre la VM ou qu’elle démarre seule au boot, elle se met en pause. Si on essaye de la sortir du mode pause on reçoit l’erreur suivante.

Error unpausing domain: internal error unable to execute QEMU command ‘cont’: Resetting the Virtual Machine is required<

L’erreur en elle même n’est pas très explicite. Dans le log de la machine virtuelle en question, on a un message plus long mais guère plus évocateur :

/var/log/libvirt/qemu/[maVM]
kvm: unhandled exit 80000021
kvm_run returned -22
If you’re running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

Bien évidemment, toutes les autres VMs sous Linux fonctionnent parfaitement donc on ne peut pas accuser Qemu de ne pas fonctionner correctement.

Solution

En théorie, j’ai lu à plusieurs endroits que le bug était censé être corrigés sur des patchs des kernels de CentOS 5 ou 6 (toujours présent en 2.6.32-431.3.1.el6.x86_64 par exemple) et même pour Ubuntu.
Dans la pratique, même en mettant l’OS CentOS à jour, impossible de faire fonctionner cette VM.
La seule vrai solution que j’avais trouvé à l’époque était de forcer le passage à un kernel plus récent, à savoir au moins 3.+.

Pour ceux qui se sentiraient un peu perdu, le plus simple est de changer de version de CentOS ou d’Ubuntu. Sur les dernière version le bug n’est plus présent.

Cependant, si vous avez un système en place et qu’une migration n’est pas à l’ordre du jour, voici la marche à suivre pour installer un kernel plus récent. Voici la procédure que j’ai utilisée pour installer un 3.13 sur lequel la VM fonctionne à nouveau (3.11 fonctionne aussi, je ne sais pas avant).

yum install gcc ncurses ncurses-devel
yum update
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.13.1.tar.gz
tar xzf linux-3.13.1.tar.gz -C /usr/src/
cd /usr/src/linux-3.13.1/
make menuconfig
make
make modules_install install

N’oubliez pas de vérifier que votre kernel est bien choisi en premier dans le boot loader, ce qui n’est souvent pas le cas par défaut (modifier la valeur default dans le grub.conf pour correspondre à la bonne entrée) sinon le problème ne sera pas résolu au reboot.

vi /etc/grub.conf
default=X
[...]
root (hd0,0)
kernel /vmlinuz-3.13.1 ro root=/dev/mapper/vg_root-lv_root rd_LVM_LV=vg_root/lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_MD_UUID=8f43b4fe:e72ed9aa:2da568b5:5f43b223 SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rd_LVM_LV=vg_endeavour/lv_swap rd_NO_DM rhgb quiet
initrd /initramfs-3.13.1.img

Et vous pouvez vérifier que vous êtes sur le bon kernel avec un uname.

reboot
uname -r

Erreur/bug Error starting virt-manager

En bonus track, je voudrais aussi ajouter un petit bug de plus pour la route, sur l’utilisation de l’interface graphique virt-manager cette fois ci.

Pour une raison obscure, lorsque je voulais lancer ma GUI virt-manager, il m’est arrivé une ou deux fois de suivre la procédure décrite sur le blog de nutanix lorsque je recevais l’erreur suivante :

Error starting virt-manager

dbus-uuidgen --get
cat /var/lib/dbus/machine-id
dbus-uuidgen > /var/lib/dbus/machine-id