Non, pas juste UN programme. L’activité de rsync qui consiste à lire et écrire de grandes quantités de données dans le système de fichiers a tendance à faire grossir le cache disque, mais ce n’est pas suffisant pour causer le problème :
J’ai pensé à cette possibilité. Comme je suis en Sid, et que je viens de passer il y a quelques jours au noyau 4.7, ça peut provenir du noyau?
Je vais faire un essai avec le noyau 4.6 pour voir.
Bon eh bien y’a pas photo, c’est un problème de kernel… (4.7 dans le dépôt unstable).
Je viens de faire le test avec le 4.6, et là pas de problème… Il respecte bien les valeurs passées à :
vm.swappiness = 0
vm.vfs_cache_pressure = 50
Voici même le résultat de “free -h” après plusieurs executions successives du script de sauvegarde, Swap activée dès le démarrage, ave Firefox (4 onglets), Chromium, 2 fenêtres Gnome-Terminal ouvertes, Icedove, Remmina (connexion rdp), moniteur système et une fenêtre Nautilus :
gogi@debtrfs:~$ free -h
total used free shared buff/cache available
Mem: 3,8G 1,9G 115M 60M 1,8G 1,6G
Swap: 6,0G 0B 6,0G
Le système reste parfaitement fluide, quelques saccades pendant l’execution du script, mais elles sont plus que négligeables (de l’ordre de 1 à 5 sec si je lance une appli ou si j’ouvre une nouvelle page dans Firefox ou Chromium par exemple…). Pour un HDD à 5400 RPM c’est plus que bien 
Peux-tu m’expliquer succintement de quelle manière agit le paramètre “vm.vfs_cache_pressure” et est-ce qu’il influence la responsivité du système en fonction de la valeur que je lui attribue?
À part ça je devrais lancer un bug aux mainteneurs pour le kernel à moins qu’il existe déjà…?
Les script que vous avez copié contient
. /usr/local/etc/backup-sys.conf
et sans le contenu de ce fichier nous ne pouvons pas comprendre ce qui se passe.
Pourriez-vous nous donner les retours de
. /usr/local/etc/backup-sys.conf
sudo mkdir $MOUNT_TARGET $MOUNT_SOURCE
sudo mount -v -t btrfs $SOURCE_DEVICE $MOUNT_SOURCE
df -hT $MOUNT_SOURCE
df -iT $MOUNT_SOURCE
sudo mount -v -t btrfs $TARGET_DEVICE $MOUNT_TARGET
df -hT $MOUNT_TARGET
df -iT $MOUNT_TARGET
et si vous voulez démonter et éventuellement supprimer les répertoires dans /mnt je vous laisse faire.
Remarquez que le passage par des variables d’environnement complique sérieusement la tâche.
A mon avis c’est le choix de btrfs comme système de fichier cible qui ne me paraît pas approprié. Vous avez choisi btrfs pour votre système, soit, par contre pour une copie de sauvegarde un FS moins sophistiqué (avec moins de consommation de mémoire comme xfs) me paraît plus pertinent.
F. Petitjean
Ingénieur civil du Génie Maritime.
« Comme la tartine, l’ivrogne tombe toujours du côté qui est complètement beurré. »
– Professeur Choron
Il n’y a rien de spécial dans ce fichier, c’est un fichier de configuration que j’ai crée pour définir les chemins pour les points de montage comme je l’ai dit dans mon précédent message, ainsi que les partitions à monter dans ces points de montage et les chemins à exclure lors de la sauvegarde…
root@blablabla:/home/gogi# cat /usr/local/etc/ba*
# FICHIER DE CONFIGURATION POUR BACKUP-SYS
#
#
# Definition des chemins de périphériques "source" et "destination de sauvegarde"
SOURCE_DEVICE='/dev/disk/by-label/linux'
TARGET_DEVICE='/dev/disk/by-label/linux-backup'
# Definition des points de montage temporaires pour les périphériques "source" et "destination de sauvegarde"
MOUNT_SOURCE='/mnt/source'
MOUNT_TARGET='/mnt/target'
# Liste des chemins à exclure dans la sauvegarde
EXCLUDE_LIST=(@debian/@tmp/*
@debian/@fsroot/dev/*
@debian/@fsroot/proc/*
@debian/@fsroot/sys/*
@debian/@fsroot/run/*
@debian/@fsroot/mnt/*
@debian/@fsroot/media/gogi/*
@debian/@fsroot/lost+found
@debian/@home/gogi/.cache/chromium/Default/*
@debian/@home/gogi/.cache/icedove/*
@debian/@home/gogi/.cache/mozilla/firefox/*
@debian/@home/gogi/.cache/thumbnails/fail/gnome-thumbnail-factory/*
@debian/@home/gogi/.cache/thumbnails/large/*
@debian/@home/gogi/.cache/thumbnails/normal/*
@debian/@home/gogi/.thumbnails/normal/*
)
Je l’ai fait un peu différemment des commandes que vous avez donné mais le résultat est le même :
root@blablabla:/home/gogi# mkdir /mnt/{source,target}
root@blablabla:/home/gogi# mount -v -t btrfs /dev/mapper/linux /mnt/source
mount : /dev/mapper/linux monté sur /mnt/source.
root@blablabla:/home/gogi# mount -v -t btrfs /dev/sdb3 /mnt/target
mount : /dev/sdb3 monté sur /mnt/target.
root@blablabla:/home/gogi# df -hT /mnt/source
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/linux btrfs 459G 145G 314G 32% /mnt/source
root@blablabla:/home/gogi# df -iT /mnt/source
Sys. de fichiers Type Inœuds IUtil. ILibre IUti% Monté sur
/dev/mapper/linux btrfs 0 0 0 - /mnt/source
root@blablabla:/home/gogi# df -hT /mnt/target
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
/dev/sdb3 btrfs 266G 144G 121G 55% /mnt/target
root@blablabla:/home/gogi# df -iT /mnt/target
Sys. de fichiers Type Inœuds IUtil. ILibre IUti% Monté sur
/dev/sdb3 btrfs 0 0 0 - /mnt/target
Mais bon comme je l’ai dit plus haut ce n’est pas ça qui pose problème finalement, ni mon choix de système de fichiers (même si je comprends parfaitement ce que vous dites), mais le dernier kernel que j’ai installé depuis le dépôt “Unstable” (la version 4.7 est d’ailleurs fraîchement sortie il y a à peine 3 jours dans ce dépôt).
En démarrant sur le noyau 4.6 (lui aussi dans le même dépôt), je n’ai plus le problème de Swap, elle reste bien à 0, même si le cache/buffer est rempli de la même manière… (voir mon message ci-dessus).
Bon en cherchant sur le net j’ai effectivement trouvé un bug similaire :
Plutôt que de risquer d’en faire une interprétation erronée, je préfère te renvoyer à la documentation du noyau : Documentation/sysctl/vm.txt
Quant à son influence sur la réactivité du système, comme toujours en matière de cache c’est une question de compromis. Le “VFS cache” (VFS pour “virtual filesystem”, abstraction du système de fichiers intermédiaire entre les systèmes de fichiers réels et les processus) contient des méta-données recueillies lors du parcours de l’arborescence du système de fichiers, ce qui évite de refaire des accès disque lorsqu’un programme a à nouveau besoin d’une information (pour ouvrir un fichier par exemple) qui se trouve déjà dans ce cache. C’est ce qui fait que ls -R / est beaucoup plus rapide à la deuxième exécution. Une valeur élevée du paramètre vfs.cache_pressure permet au noyau de réclamer plus facilement la mémoire occupée par le cache VFS (en supprimant des données) plutôt que la mémoire occupée par d’autres caches de données des disque. Une valeur très élevée risque de ralentir le système en réduisant trop la taille de ce cache et donc en augmentant les accès disques pour les données manquantes. Une valeur trop basse peut aussi ralentir le système en allouant trop d’espace à ce cache, conservant en mémoire des données inutilisées depuis longtemps, au détriment de la conservation de données plus “fraîches” par les autres caches.
Ah ? Il me semblait pourtant que XFS était assez consommateur de mémoire. Je me rappelle d’un bug du noyau concernant un possible épuisement de la mémoire lors d’une opération particulière au montage d’un système de fichiers XFS volumineux.
Très bien ça va me faire un peu de lecture 
La meilleure chose reste donc à tester plusieurs valeurs jusqu’à trouver le bon compromis pour moi…
Ok, c’est exactement ce que je voulais savoir.
En réalité le VFS n’occupe pas réellement de la place en mémoire… Il ne concerne, si je comprends bien, que les applis qui accèdent à des données présentes sur le disque? Par exemple ça ne concerne pas directement le surf sur internet, où je pourrais avoir plusieurs onglets ouverts dans Firefox?
Et enfin avec une valeur elevée (comme celle de 100 par défaut par exemple), le noyau va réclamer et remplacer au besoin les données dans le vfs_cache plus facilement qu’avec une valeur basse qui aura tendance à conserver les données?
Je n’ai pas l’impression que ce soit la meme chose. Tu n’as pas rapporté de problème d’OOM (out of memory killer, la function du noyau qui tue des processus pour libérer de la mémoire) mais seulement de swap quand ce dernier est activé.
Non c’est vrai, mais il parle bien de mémoire cache qui a tendance à occuper pratiquement tout l’espace, et peut-être n’a t-il pas de Swap sur son système tout simplement…
En ce qui me concerne c’est vrai que je ne l’ai pas mentionné mais en fait j’ai réactivé la Swap car la première où c’est arrivé j’avais pléthore d’applis ouvertes et j’ai eu droit à un joli freeze de mon système avec pour seule issue d’éteindre le PC de manière barbare avec le bouton dállumage/extinction… 
Enfin selon la coincidence est quand même grosse je trouve pour ne pas être similaire, je verrai bien lorsque le patch sera définitivement intégré dans une version supérieure de ce noyau 4.7, je ferai le test et on verra.
Une dernière question au sujet de VFS : je viens de lire le lien que tu m’a donné tout à l’heure et j’ai compris ce que tu as dis au sujet de l’accès aux données plus rapide à partir d’un 2e accès au moins (exemple avec ls -R /).
Mais est-ce que c’est aussi valable pour l’accès aux applications elles-même? Par exemple si j’ai au moins une fois ouvert le programme Blender on va dire, est-ce que le VFS_cache agit aussi lorsque je ferme Blender et que je le réouvre plus tard?
Ah, j’avais cru comprendre que les problèmes n’avaient commencé que lorsque tu as activé le swap.
En partie puisque le cache VFS contient déjà les informations sur les répertoires et fichiers utilisés par le programme. Par contre le contenu des fichiers déjà lus se trouve dans un autre cache appelé “pagecache”, dont la taille est affichée dans la colonne “cache” de la sortie de la commande free.
On peut comparer l’impact de l’éviction des données contenues dans ces deux caches en écrivant 1 (pour libérer le pagecache) ou 2 (pour libérer le cache de répertoires et d’inodes) dans le paramètre noyau vm.drop_caches. La valeur 3 libère les deux, c’est un OU binaire.
En fait non, depuis que je suis passé en btrfs et que j’ai mis mon disque au format GPT et crypté les partitions avec LUKS, j’avais laissé la swap en attente.
Entre temps j’ai eu deux trois mega-freeze (deux parce que je l’ai cherché, et un avec rsync donc recemment). Mais bon c’est vrai je ne l’avais pas mentionné au début du sujet.
Bon juste une petite parenthèse pour ceux qui pourraient tomber sur le sujet et chercheraient une réponse pour désactiver temporairement la Swap avec systemd (temporairement sous-entend jusqu’à une MàJ du noyau…).
Donc pour ceux qui sont sous systemd, il est un peu plus délicat de désactiver la Swap que de simplement commenter la ligne correspondante dans
# /etc/fstab
Non seulement il vous faut commenter cette ligne si vous l’avez (sous systemd elle n’est en effet pas nécessaire, comme il crée des unités pour tout, il peut s’en passer…), mais en plus il faut désactiver la/les unités correspondantes dans systemd .
Tout d’abord récuperer la liste des unités présentes et affectées à Swap :
root@blablabla:/home/gogi# systemctl list-units | grep swap
sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda3.device loaded active plugged SAMSUNG_HM500JI swap
dev-sda3.swap loaded active active Swap Partition
swap.target loaded active active Swap
Bien entendu, contrairement à des services, il est impossible d’utiliser la commande
# systemctl disable xxxx.target
pour désactiver une telle unité.
Ce qu’il faut donc faire ici pour désactiver la Swap, c’est tout simplement repérer la ligne correspondante au pérpihérique de la Swap, et le “masquer” :
# systemctl mask dev-sdxx.swap
où “xx” est à remplacer par la lettre et le numéro de la partition correspondante…
Si vous souhaitez désactiver la Swap dans la session courante sans redémarrer, il vous faudra peut-être quand même entrer à la suite la commande
# swapoff -a
Sinon le résultat sera effectif au prochain redémarrage.
Pour réactiver l’opération inverse, et au cas où vous auriez oublié quelle est la dénomination exacte du périphérique Swap dans systemd, il faudra passer les commandes suivantes :
# systemctl list-unit-files | grep swap
dev-sda3.swap masked
swap.target static
(Ici l’autre commande systemctl list-units n’affichera pas “dev-sdxx.swap” car on l’a masquée).
Puis :
# systemctl unmask dev-sdxx.swap
Là normalement pas besoin de faire un “swapon -a”, l’opération de réactivation se fait automatiquement.