Sur mon Gdium, j'ai longtemps constaté des moments où le système ne réagissait plus pendant plusieurs secondes. Je n'ai pas trouvé d'explication convaincante jusqu'à il y a peu. J'ai perdu la trace de l'article, mais en substance, la RAM est utilisée pour 3 choses:

• les programmes en cours d'exécution
• le cache des inodes et répertoires
• les données récemment lues depuis le disque (cache)

Le système de mémoire virtuelle peut, afin d'utiliser la mémoire optimalement, déplacer certaines de ces données vers le disque dur (pagination, ou plus communément swap) ou les supprimer (dans le cas des caches, puisque les données en RAM sont déjà sur le disque).

Si les programmes en cours d'exécution sont swappés, ils doivent d'abord être rapatriés en mémoire avant d'être exécutés. Lorsque ce code réagit aux actions de l'utilisateur (affichages, gestion de la souris ...), la sensation de réactivité diminue très fort.

Le cache des inodes et répertoires contient, pour faire court, la structure de l'arborescence des fichiers qui a déjà été visitée, afin d'éviter de la récupérer à chaque fois en accédant au disque dur. Avoir cette information en mémoire a un gros impact sur certaines fonctions très courantes, telles que le listage des répertoires dans l'explorateur ou l'auto-complétion dans le shell.

Le cache disque contient les données lues depuis le disque, puisqu'elles sont susceptibles d'êtres relues dans les instants suivants.

Lors de manipulations de fichiers, les paramètres par défaut sont trop généreux pour le cache disque, et des pages de mémoire contenant des programmes ou le cache des inodes son déplacés vers le swap pour laisser de la place au cache disque. Une fois la manipulation terminée, tout code qui a été mis en swap devra être à nouveau recopié en mémoire avant d'être à nouveau exécuté. Dans mon cas, la combinaison de la mémoire limitée et de la lenteur du stockage de masse (une clé USB sur le Gdium) amplifiait le problème: une manipulation de fichier causait presque à coup sûr le swap de code constamment utilisé, et récupérer ce code en RAM était lent.

La solution

Le kernel dispose de nombreux paramètres pour contrôler la gestion de la mémoire virtuelle. Dans les sources, ils sont documentés dans Documentation/sysctl/vm.txt. Deux d'entre eux permettent de résoudre mon problème:

vm.swappiness

Ce paramètre indique si le kernel doit swapper en dernier recours (valeur basse) ou toujours (valeur élevée). La valeur par défaut est 60, mais un système interactif demande des valeurs basses. J'ai réglé la valeur de ce paramètre à 10, et le système est déjà beaucoup plus réactif.

vm.vfs_cache_pressure

Ce paramètre indique si le kernel doit tenter de garder le cache des inodes en RAM (petite valeur) ou au contraire l'abandonner dès que de la RAM est nécessaire pour d'autres choses. La valeur par défaut est 100, et je l'ai réglée à 50. Utiliser une valeur trop basse risque de monopoliser la mémoire pour cette fonction.

Ces paramètres peuvent être entrés dans /etc/sysctl.conf (sous Debian, on peut aussi utiliser /etc/sysctl.d/local.conf), avec les lignes suivantes:

vm.swappiness=10
vm.vfs_cache_pressure=50

Les paramètres seront actifs au prochain redémarrage, mais peuvent être appliqués immédiatement avec la commande sysctl -p. Tout cela se fait bien entendu aux dépens du cache disque, mais sur ce genre de système, le gain en réactivité vaut largement cela.