Salut Olivier,
C'est intéressant : merci de ton retour.
En fait, le problème est un problème de... virtualisation.
Par défaut, un OS n'est pas écrit pour faire tourner un OS, mais des
processus. Ici, le processus est un OS (ou une VM pour faire plus
simple). Donc il est « normal » que l'hôte gère l'OS comme un
processus.
Ceci devrait se régler en changeant les règles et c'est le rôle de la
virtualisation : soit on tune l'OS de base, soit celui qui tourne
virtuellement... Idéalement, on peut faire les deux (c'est ce qui se
passe pour les IO par exemple : on court-circuite certaines couches
pour accélérer le processus dans kvm (c'était une avancée du grand
génie (méconnu) qu'est Fabrice Bellard).
Il est recommandé de ne pas mettre de swap pour les OS virtualisés
d'ailleurs... pour ne pas tomber dans le problème que tu viens de
rencontrer ;-)
L'idéal est d'avoir la maîtrise complète des deux OS pour optimiser
les choses (le cas extrême étant ... les conteneurs).
PK
Le sam. 11 janv. 2020 à 21:29, Olivier Allard-Jacquin
<olivieraj@???> a écrit :
>
> Bonjour,
>
> suite à une discussion sur la liste (27/11/2019 à 21:24), j'avais parlé
> du "swappiness":
>
> # cat /proc/sys/vm/swappiness
> 60
>
> C'est un mécanisme qui va gérer la manière dont la machine va utiliser
> le swap. Plus la valeur est élevée, plus le kernel s'autorisera à
> utiliser le swap, au dépend des performances I/O de la machine. Pour
> les détails:
> https://fr.wikipedia.org/wiki/Espace_d%27%C3%A9change#Noyau_Linux
>
> La machine de test:
> - Une machine avec 8Go de ram
> - /dev/sda , qui contient un swap de 8Go, plus une VM (Machine
> Virtuelle) Windows, dont on veut backuper les données
> - /dev/sdb, un disque de backup, formaté en ext4
> - 4Go de mémoire sont alloués à la VM (VirtualBox)
> - la machine exécute la VM, et partage le répertoire de données en SMB/CIFS
> - sur le Linux, le répertoire de donnée de la VM est monté via SMB/CIFS,
> et le rsync est lancé
> - un "gkrellm" http://gkrellm.srcbox.net/ permet de surveiller tout ce
> petit monde, et notamment les lectures/écritures sur chacun des disques
>
> Sur le papier, je m'attends à de bonnes perfs, vu que les lectures sont
> faites sur un disque (/dev/sda), et les écritures sur un autre
> (/dev/sdb). En fait, la seule limitation doit être l'interface réseau de
> la VM (1Gpbs, soit 120Mo/s max)
>
> Dans les faits, les perfs sont moyennes:
> - En fait, le disque /dev/sda plafonne à 30Mos/ en lecture, voir moins.
> - Le /dev/sdb fait des "rafales" d'écriture à 160Mo/s, et a de longs
> moment d'inactivité. Donc le problème ne vient pas de lui
> - Plus choquant, le /dev/sda indique des ECRITURES, et parfois, il lit
> autant qu'il écrit des données. Ca, c'est anormal.
> - J'ai pesté et cherché du côté Windows, mais toutes les informations
> ("perfmon.exe" notamment) indiquent qu'il n'écrit pas beaucoup de
> données ...
> - alors, où est se cache le loup ?
>
> En fait, le problème est le swap de Linux :
> - il utilise toute la ram disponible afin de faire du cache pour les
> accès disques (/dev/sda en lecture et /dev/sdb en écriture)
> - et pour maximiser encore plus le cache, il charge le swap de pages
> mémoire peu utilisées. Et notamment, je pense qu'il swape des pages de
> mémoire de VirtualBox
> - ce qui amène à une situation assez ridicule:
> - le Windows dans sa VM utilise (lui aussi) au maximum ses 4Go de
> mémoire, afin de faire du cache disque pour les fichiers lus à travers
> le SMB/CIFS
> - donc la mémoire (linux) de la VM (VirtualBox) se charge de pages pas
> très utiles (les fichiers ne sont lus qu'une seule fois)
> - cette mémoire étant peu utilisés, elle est écrite sur le swap du linux
> - ces opérations d'écritures de swap rentrent en conflit avec celles de
> lecture de la VM, d'où les perfs qui s'écroulent ...
>
> Solution:
> - le plus logique serait que cache de Windows soit désactivé, afin que
> les opérations de cache disque ne soient faite qu'une seule fois, au
> niveau du cache de Linux. C'est peut-être faisable, mais c'est du
> Windows, donc cela ne nous concerne pas sur cette liste
> - une solution assez "violente", est de désactiver le swap Linux
> (commande "swapoff -a"). Mais sans swap du tout, la machine ne pourra
> pas allouer plus de 8Go de mémoire, ce qui peut être un problème
> - finalement, une solution assez bonne est de réduire la priorité du
> swap, afin que le kernel Linux ne l'utilise qu'en dernière option. Cela
> va naturellement réduire le cache disque, ce qui est peut être
> problématique. Après différents tests, j'ai trouvé que ceci donne un bon
> résultats:
>
> echo 20 > /proc/sys/vm/swappiness
>
> - finalement après reconfiguration, les perfs attendus sont de retour
> (100Mo/s pour le rsync entre la VM et le disque de backup)
>
> Conclusions:
> - Dans le cas d'une machine faisant tourner des VM, le swap n'est pas
> forcément une bonne idée
> - Trouver la cause de la perte de performance n'est pas évident
> (surveillance et identification de l'activité du swap).
>
> Cordialement,
>
> Olivier
> --
> ~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Phoenix / _ \/ _ \ Olivier Allard-Jacquin
> / / \ / \ \ Web: http://olivieraj.free.fr/
> /___/ / \ \___\ Mail: olivieraj@???
> ~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
>
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
