[technique] Avis sur analyse de graphe performance serveur

Dim 16 Oct 20:56:48 CEST 2022

Bonsoir,

Pour moi swapiness 60 et tous les paramètres kernel par défaut, sauf 
appli qui abuse, normalement ça marche bien, en tout cas pour moi avec 
~100 VM debian. Appli qui abuse : en général écrite en java :o)

Les 3 courbes roses dans le graphe memory n'aide pas pour une analyse. 
Au pire : apt install munin pour quelques temps. Il fait des graphes 
moche *mais* réellement utilisables. Merci rrdtool et la config par 
défaut qui va bien depuis l'an 2000-quelque chose petit. 100% des 
graphes memory que je vois hors munin tous tous archi nuls :-/

Ça serai intéressant de regarder au fil de la journée quels programmes 
mangent de la RAM. atop (avec atopsar je crois me souvenir) permet de 
voir l'équivalent d'un "top" et de remonter dans le temps avec les 
flèches du clavier, dans une vue ncurses avec la liste des process, y 
compris ceux qui n'ont vécu que moins de 5 minutes. (ça m'a déjà sauvé 
pour comprendre que le pb venait d'une cron qui faisait un maxi pic 
d'alloc VM pendant 1 seconde puis exit sur une VM à des heures pas 
systématiques à cause d'une appli ayant installé un */5 * * * * * cron.php).

J'ai passé 10 ans avec pas de swap du tout dans les VM, et dans la 
dernière univ où je suis, j'ai un modèle de VM debian 11 avec un petit 
swap (200Mo) qui est une partition au début de mes VM (pour pas coincer 
les jours d'agrandissement de la partition racine en fin de disque et 
enbonus, ptet elle deviendra une partition EFI un jour), car dans 
certains cas pas hyper clair, notamment avec des tomcat, le no swap ça 
fait un peu trop facilement des OOMkiller kernel (et l'infra en question 
n'a pas des téra de RAM en rab').

Ce qui suit n'est vraisemblablement pas ton cas de figure car on voit le 
cache (supposément, rose du bas) baisser dans la journée, c'était pas 
mon cas.

Dans les noyaux 5.x à partir de je ne sais pas vraiment quelle version, 
avec les cgroups v2 et des changements dans linux, il semble qu'il 
arrive que linux préfère swapper des pages plutôt que jeter des pages en 
cache RAM. Plein de documents, y compris récents, expliquent que ça 
n'existe pas. Et ça semble vrai aussi. Pas clair pour moi. En pratique, 
j'ai eu un même problème sur 5 VM sur 45 issue du même modèle debian 
11), les plus sollicitées par des usagers. Au bout 'un semaine ou deux 
d'uptime, >80% swap occupé, cache RAM pas vide du tout (et plus gros que 
le swap!) et pas de process connu qui fasse un gros spike avec un 
malloc(beaucoup) puis free() peu après.

Pour voir ce qui est dans le cache des MV bizares, j'ai utilisé (en 
root) des variantes (attention si vous avez plusieurs partitions montées 
, faut les lister) de :

# find / -mount -type f -size +1M -print0 | xargs -r0 fincore | sort -rh 
| head -n100

J'ai constaté que j'avais un cache plein de fichiers qui ne seront juste 
très probablement jamais lus. Des logs rotatés, des 
/var/lib/automysqlbackup/*/*.gz, des /var/log/journal/* vieux. Et par 
contre, les 3/4 des fichiers du /var/lib/mysql qui est important sur ma 
VM... pas dans le cache. B*del.

fincore c'est excellent pour commencer, mais ça ne dit pas qui a fait 
rentrer lesdits fichiers dans le cache. Ni comment sortir un fichier du 
cache. J'ai pas trop cherché de solution sur étagère pour ça (j'ai lu 2 
stackoverflow longs, ça m'a gavé, j'ai apt search des trucs, rien, j'ai 
fermé firefox et ouvert vim). J'ai écrit un dontneed.c en 30 lignes qui 
appelle fadvise(..., DONTNEED...) pour tous les fichiers qui lui sont 
passés en argument (pas trouvé tout fait ça dans debian !). J'ai 
manuellement dégagé les trucs "débiles" du cache des VM qui déconnaient. 
J'ai swapoff -a && swapon -a aussi. Le lendemain, ils étaient re-là les 
fichiers nuls dans le cache. Et le swap avait augmenté, grr...

Conclusion de l'aventure : j'ai dû emballer l'agent de backup TINA 
(choix indépendant de ma volonté sinon... bref :D) dans une unité 
systemd avec un MaxMemory=256M. Il ne consomme jamais bcp de RAM (en 
terme de malloc() ), mais lorsqu'il fread() un gros tas des fichiers de 
ma VM en séquence pour les envoyer au serveur de backup il oublie 
d'appeler fadvise(...DONTNEED...). Avec cette unité systemd, il arrête 
"d'empoisonner" le cache tous les soirs avec des fichiers "à la con". 
Après ça, le swap-in dans mes VM qui avaient le pb est revenu à presque 
0. J'ai ajouté un post hook à mon automysqlbackup (qui lui non plus ne 
fait pas des fadvise) pour appeler mon ./dontneed avec tous les fichiers 
sql.gz produits). (oui j'avais des VM avec des gros dump à cause d'un 
bon gars qui a cru que SQL BLOB est une idée ok pour stockage de 
fichiers :D)

Plus de problèmes. Les VM en question arrivent parfois à reswapper un 
peu, par fois 180Mo en 3 ou 4 semaines. Mais comme j'ai 
unattended-upgrade actif et qu'il y a des secu update de kernel ou qui 
demandent un reboot a peu près à cette fréquence là... reboot et swap 
vide donc.

Ce même agent TINA qui fait pas de fadvise dans un debian 10, sur une VM 
avec même appli et même trafic (notamment l'intranet de la fac qui était 
en deb10 avant réinstall en deb11) avec un kernel 4.x et les cgroups v1, 
a certainement un listing de cache tout nul mais jamais ça ne conduit à 
avoir un swap plein. C'est un truc "nouveau" pour moi ces "problèmes" 
(sous-optimalités diront d'autres).

Ludo

Le 15/10/2022 à 20:31, Marc_marc via technique a écrit :
> Bonjour,
>
> Le 15.10.22 à 12:07, Matthieu Herrb via technique a écrit :
>> S'il s'agit d'une machine virtuelle, il vaut mieux ne pas configurer 
>> de swap du tout ou alors forcer swapiness à 0.
>
> il me semblait avoir lu (mais je ne retrouve pas la source)
> que swapiness=0 n'avait pas l'effet attendu sur tous les noyeau
> et perso j'utilise swapiness=1 qui a en pratique le même effet.
>
> Cordialement,
> Marc
>
>
> _______________________________________________
> technique mailing list
> technique at lists.tetaneutral.net
> http://lists.tetaneutral.net/listinfo/technique

-- 
Ludovic Pouzenc
www.pouzenc.fr