J'ai un ordinateur portable Debian (Buster) avec 8 Go de RAM et 16 Go d'échange. Je lance une très longue tâche en cours d'exécution. Cela signifie que mon ordinateur portable est resté allumé pendant les six derniers jours pendant qu'il passe à travers.

Ce faisant, je dois régulièrement utiliser mon ordinateur portable comme ordinateur portable. Cela ne devrait pas être un problème. la tâche longue est liée aux E / S, passe par des tâches sur un disque dur USB et ne nécessite pas beaucoup de RAM (<200 Mo) ou de CPU (<4%).

Le problème est que lorsque je reviendrai à mon ordinateur portable au bout de quelques heures, ce sera très lent et 30 minutes peuvent être nécessaires pour revenir à la normale. Cela est si grave que les contrôleurs d'incident signalent que leurs applications respectives sont gelées (en particulier les fenêtres du navigateur) et que les incidents qui se produisent entraînent une défaillance incorrecte.

En regardant sur le moniteur système, des 2,5 Go utilisés, environ la moitié est basculée en swap. J'ai confirmé le problème en supprimant l'espace de permutation ( swapoff /dev/sda8). Si je le laisse sans espace d'échange, il revient à la vie presque instantanément, même après 24 heures. Avec swap, c'est pratiquement une brique pour les cinq premières minutes, n'ayant été laissée que six heures. J'ai confirmé que l'utilisation de la mémoire ne dépasse jamais 3 Go, même en mon absence.

J'ai essayé de réduire le swappiness ( voir aussi: Wikipedia ) aux valeurs de 10et 0, mais le problème persiste. Il semble qu'après un jour d'inactivité, le noyau estime que la totalité de l'interface graphique n'est plus nécessaire et l'efface de la mémoire vive (la permute sur le disque). La longue tâche consiste à lire une vaste arborescence de fichiers et à lire chaque fichier. Il se peut donc que le noyau ait du mal à croire que la mise en cache aiderait. Toutefois, sur un seul disque dur USB HD de 2 To avec environ 1 milliard de noms de fichiers, une Go de RAM supplémentaire n’aidera pas beaucoup les performances. Ceci est un ordinateur portable pas cher avec un disque dur lent. Il ne peut tout simplement pas charger les données dans la RAM assez rapidement.

Comment puis-je dire à Linux d'utiliser uniquement l'espace de swap en cas d'urgence? Je ne veux pas courir sans échange. Si quelque chose d'inattendu se produit et que le système d'exploitation a soudainement besoin de quelques Go supplémentaires, je ne veux pas que les tâches soient détruites et je préférerais commencer à utiliser le swap. Mais pour le moment, si je laisse la permutation d'échange activée, mon ordinateur portable ne peut tout simplement pas être utilisé quand j'en ai besoin.

La définition précise du terme "urgence" pourrait faire l’objet d’un débat. Mais pour clarifier ce que je veux dire: une urgence serait où le système est laissé sans autre option que d’échanger ou de tuer des processus.

Qu'est-ce qu'une urgence? - As-tu vraiment besoin de demander? ... J'espère que tu ne te retrouveras jamais dans un immeuble en feu!

Il m'est impossible de définir tout ce qui pourrait constituer une urgence dans cette question. Mais par exemple, une urgence peut survenir lorsque le noyau est tellement sollicité pour la mémoire qu'il a commencé à tuer des processus avec le KOM Killer . Une urgence n'est PAS lorsque le noyau pense qu'il peut améliorer les performances en utilisant swap.

Final Edit: j'ai accepté une réponse qui répond exactement à ce que j'ai demandé au niveau du système d'exploitation. Les futurs lecteurs devraient également prendre note des réponses proposant des solutions au niveau de l'application.

Avoir un échange aussi important de nos jours est souvent une mauvaise idée. Au moment où le système d'exploitation n'a échangé que quelques Go de mémoire, votre système avait déjà explosé (comme ce que vous avez vu).

Il est préférable d' utiliser zramavec une petite partition d'échange de sauvegarde . De nombreux systèmes d'exploitation tels que ChromeOS, Android et diverses distributions Linux activent zram par défaut depuis des années, en particulier pour les systèmes dotés de moins de RAM. C'est beaucoup plus rapide que le swap sur disque dur et vous pouvez clairement sentir la réactivité du système dans ce cas. Moins sur un SSD, mais selon les résultats du test de performance, cela semble toujours plus rapide, même avec l'algorithme lzo par défaut. Vous pouvez passer à lz4 pour des performances encore meilleures avec un taux de compression légèrement inférieur. Sa vitesse de décodage est presque 5 fois plus rapide que celle de LZO, selon les critères officiels.

Il y a aussi zswapbien que je ne l'ai jamais utilisé. Probablement la peine d'essayer et comparer lequel est le mieux pour vos cas d'utilisation

Après cela, une autre suggestion consiste à réduire la priorité de ces processus liés aux entrées-sorties et à laisser éventuellement un terminal s'exécutant sur une priorité plus élevée afin que vous puissiez exécuter des commandes sur celui-ci immédiatement même lorsque le système est chargé.

Lectures complémentaires

• https://wiki.debian.org/ZRam
• https://wiki.archlinux.org/index.php/improving_performance#RAM_and_swap
• zram vs zswap vs zcache Guide ultime: quand utiliser lequel
• Linux, SSD et swap
• Différence entre ZRAM et ZSWAP
• https://www.kernel.org/doc/Documentation/blockdev/zram.txt
• https://wiki.gentoo.org/wiki/Zram

Un correctif consiste à vérifier que le contrôleur cgroup de mémoire est activé (je pense que c'est par défaut dans les noyaux même semi-récents, sinon vous devrez ajouter des éléments cgroup_enable=memoryà la ligne de commande du noyau). Vous pouvez ensuite exécuter votre tâche intensive d'E / S dans un groupe de contrôle avec une limite de mémoire, ce qui limite également la quantité de mémoire cache qu'il peut consommer.

Si vous utilisez systemd, vous pouvez définir +MemoryAccounting=yeset MemoryHigh/ MemoryMaxou MemoryLimit(dépend de si vous utilisez cgroup v1 ou v2) dans l’unité ou une tranche le contenant. Si c'est une tranche, vous pouvez utiliser systemd-runpour exécuter le programme dans la tranche.

Exemple complet d’un de mes systèmes pour l’exécution de Firefox avec une limite de mémoire. Notez que ceci utilise cgroups v2 et qu'il est configuré en tant qu'utilisateur, pas en tant qu'utilisateur root (l'un des avantages de v2 par rapport à v1 est que la délégation de cette opération à non-root est sûre, donc c'est ce que systemd fait).

$ systemctl --user cat mozilla.slice 
# /home/anthony/.config/systemd/user/mozilla.slice
[Unit]
Description=Slice for Mozilla apps
Before=slices.target

[Slice]
MemoryAccounting=yes
MemoryHigh=5G
MemoryMax=6G

$ systemd-run --user --slice mozilla.slice --scope -- /usr/bin/firefox &
$ systemd-run --user --slice mozilla.slice --scope -- /usr/bin/thunderbird &

J'ai trouvé que pour que l'utilisateur travaille, je devais utiliser une tranche. Le premier système fonctionne simplement en mettant les options dans le fichier de service (ou en utilisant systemctl set-propertyle service).

Voici un exemple de service (utilisant cgroup v1), notez les deux dernières lignes. Cela fait partie de l'instance système (pid = 1).

[Unit]
Description=mount S3QL filesystem
Requires=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=forking
User=s3ql-user
Group=s3ql-user
LimitNOFILE=20000
ExecStartPre=+/bin/sh -c 'printf "S3QL_CACHE_SIZE=%%i\n" $(stat -c "%%a*%%S*.90/1024" -f /srv/s3ql-cache/ | bc) > /run/local-s3ql-env'
ExecStartPre=/usr/bin/fsck.s3ql  --cachedir /srv/s3ql-cache/fs1 --authfile /etc/s3ql-authinfo  --log none «REDACTED»
EnvironmentFile=-/run/local-s3ql-env
ExecStart=/usr/bin/mount.s3ql --keep-cache --cachedir /srv/s3ql-cache/fs1 --authfile /etc/s3ql-authinfo --cachesize ${S3QL_CACHE_SIZE} --threads 4
ExecStop=/usr/bin/umount.s3ql /mnt/S3QL/
TimeoutStopSec=2m
MemoryAccounting=yes
MemoryLimit=1G

La documentation est en systemd.resource-control(5).

Il semble qu'après un jour d'inactivité, le noyau estime que la totalité de l'interface graphique n'est plus nécessaire et l'efface de la mémoire vive (la permute sur le disque).

Le noyau fait The Right Thing ™ en le croyant. Pourquoi garderait-il ¹ mémoire inutilisée dans la RAM et la gaspillerait donc au lieu de l’utiliser comme cache ou quelque chose de ce genre?

Je ne pense pas que le noyau Linux permute les pages de manière gratuite ou anticipée. Par conséquent, si cela se produit, vous devez stocker autre chose sur de la RAM, ce qui améliore les performances de votre tâche de longue durée, ou du moins avec cet objectif.

Si vous savez à quel moment vous devez réutiliser votre ordinateur portable à l’avance, vous pouvez utiliser la atcommande (ou crontab) pour planifier un nettoyage de swap ( swapoff -a;swapon -a).

Comme le nettoyage de l’échange risque d’être excessif et même de déclencher le tueur de MOO si, pour une raison quelconque, tout ne tient pas dans la RAM, vous pouvez simplement "annuler l’échange" ^{2 de} tout ce qui concerne les applications en cours que vous souhaitez réactiver.

Une façon de le faire consiste à attacher un débogueur similaire gdbà chacun des processus affectés et à déclencher une génération de vidages mémoire:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

Comme vous l'avez écrit, votre longue application ne réutilise pas les données lues après le premier passage. Vous êtes donc dans un cas spécifique où la mise en cache à long terme n'est pas utile. Ensuite, contourner le cache en utilisant une E / S directe comme suggéré par Will Crawford devrait être une bonne solution de contournement.

Sinon, vous pourriez régulièrement vider le cache de fichiers en écho 1ou 3le /proc/sys/vm/drop_cachespseudo-fichier avant le système d' exploitation pense qu'il est une bonne idée d'échanger vos applications graphiques et de l' environnement.

Voir Comment vider les mémoires tampons et le cache sur un système Linux? pour plus de détails.

¹ _{Inutilisé en ce sens: plus utilisé activement depuis une période de temps significative, la mémoire étant toujours pertinente pour ses propriétaires.}
² _{Remettez dans la RAM les pages stockées dans la zone de swap.}

Le processus que vous exécutez est-il quelque chose que vous avez créé vous-même?

Si tel est le cas, il pourrait être intéressant d’ajuster votre code pour ouvrir les fichiers à l’aide du O_DIRECTdrapeau, qui cite la page de manuel -

Essayez de minimiser les effets de cache des E / S vers et depuis ce fichier. En général, cela dégrade les performances, mais cela s'avère utile dans des situations spéciales, par exemple lorsque les applications font leur propre mise en cache. Les entrées / sorties de fichiers sont effectuées directement vers / depuis les tampons d'espace utilisateur. L'indicateur O_DIRECT s'efforce à lui seul de transférer des données de manière synchrone, mais ne donne pas les garanties de l'indicateur O_SYNC que les données et les métadonnées nécessaires sont transférées. Pour garantir des E / S synchrones, O_SYNC doit être utilisé en plus de O_DIRECT. Voir NOTES ci-dessous pour une discussion plus approfondie.

Voici une idée que je n'ai pas essayée moi-même (et je suis désolée de ne pas avoir le temps de faire des expériences avec cela).

Supposons que vous créiez une petite machine virtuelle avec seulement 512 Mo de mémoire pour votre traitement en arrière-plan. Je ne suis pas sûr que vous souhaitiez un échange, votre appel, et le désactiver sur votre système hôte.

Supprimez le swap ou diminuez-le d’environ 20% (cela peut varier selon les systèmes ), car récemment, les systèmes d’exploitation n’utilisent plus le swap de la même manière qu’il ya quelques années. Cela répond probablement à certaines de vos questions:

-> redhat.com officiel

certaines des infos Red Hat ci-dessous,

Dans le passé, certains éditeurs d’applications recommandaient d’échanger une taille égale à la RAM, voire deux fois plus. Imaginons maintenant le système susmentionné avec 2 Go de RAM et 2 Go d’échange. Une base de données sur le système a été configurée par erreur pour un système doté de 5 Go de RAM. Une fois la mémoire physique épuisée, l'échange est utilisé. Comme le disque d'échange est beaucoup plus lent que la RAM, les performances diminuent et des ralentissements se produisent. À ce stade, même les connexions au système peuvent devenir impossibles. Au fur et à mesure que de plus en plus de mémoire est écrite, les mémoires physique et d'échange sont complètement épuisées et le tueur OOM entre en action, tuant un ou plusieurs processus. Dans notre cas, il y a beaucoup de swaps disponibles, le temps de mauvaise performance est donc long.

et

https://wiki.debian.org/Swap

portion du lien Debian ci-dessus,

Informations et considérations relatives à la quantité de swap à utiliser:

"La quantité recommandée d'espace de permutation correspond généralement au double de la quantité de mémoire système. Au fil du temps, elle est passée à une fois et demie la mémoire système. Il existe de nombreuses variables concernant votre système et l'utilisation prévue qui détermineront l'échange système que vous souhaitez effectuer. "

Vous pouvez essayer:

"Le meilleur moyen de désactiver swap sous Linux"

Note personnelle:

Depuis que j'ai 6 Go de RAM et dans tous mes OS récemment sous Linux. Je n'ai jamais vu aucune indication d'utilisation de Swap. J'ai déterminé que je devais l' éteindre soit pour l'espace (quelques giga-octets de plus), soit parce que cela ralentissait parfois mon système.