Une solution consiste à s'assurer que le contrôleur de groupe de contrôle de la mémoire est activé (je pense que c'est par défaut même dans les noyaux semi-récents, sinon vous devrez ajouter cgroup_enable=memory à la ligne de commande du noyau). Ensuite, vous pouvez 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 cache qu'elle peut consommer.
Si vous utilisez systemd, vous pouvez définir +MemoryAccounting=yes et soit MemoryHigh /MemoryMax ou MemoryLimit (selon si vous utilisez cgroup v1 ou v2) dans l'unité, ou une tranche le contenant. Si c'est une tranche, vous pouvez utiliser systemd-run pour exécuter le programme dans la tranche.
Exemple complet d'un de mes systèmes pour exécuter Firefox avec une limite de mémoire. Notez que cela utilise cgroups v2 et est configuré en tant que mon utilisateur, pas root (l'un des avantages de v2 par rapport à v1 est que déléguer cela à non-root est sûr, donc systemd le 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 faire fonctionner l'utilisateur, je devais utiliser une tranche. Le système un fonctionne simplement en mettant les options dans le fichier de service (ou en utilisant systemctl set-property sur le 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 une journée d'inactivité, le noyau pense que l'intégralité de l'interface graphique n'est plus nécessaire et l'efface de la RAM (la remplace sur le disque).
Le noyau fait The Right Thing™ le croire. Pourquoi garderait-il de la mémoire inutilisée dans la RAM et la gaspillerait-il au lieu de l'utiliser comme cache ou quelque chose ?
Je ne pense pas que le noyau Linux échange des pages gratuitement ou par anticipation, donc s'il le fait, ce doit être pour stocker autre chose sur la RAM, améliorant ainsi les performances de votre tâche de longue durée, ou du moins avec cet objectif.
Si vous savez à l'avance quand vous devrez réutiliser votre ordinateur portable, vous pouvez utiliser le at commande (ou crontab ) pour programmer un nettoyage de swap (swapoff -a;swapon -a ).
Comme le nettoyage de l'échange peut être exagéré, et même déclencher le tueur OOM si pour une raison quelconque, tout ne tient pas dans la RAM, vous pouvez simplement "déséchanger" tout ce qui concerne les applications en cours d'exécution que vous souhaitez relancer.
Une façon de le faire serait d'attacher un débogueur comme gdb à chacun des processus concernés et déclencher une génération de core dump :
# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit
Comme vous l'avez écrit, votre application de longue durée ne réutilise pas les données qu'elle lit après le passage initial, vous vous trouvez donc dans un cas spécifique où la mise en cache à long terme n'est pas utile. Ensuite, contourner le cache en utilisant des E/S directes comme suggéré par Will Crawford devrait être une bonne solution de contournement.
Alternativement, vous pouvez simplement vider régulièrement le cache de fichiers en faisant écho à 1 ou 3 au /proc/sys/vm/drop_caches pseudo-fichier avant que le système d'exploitation ne pense que c'est une bonne idée d'échanger vos applications et votre environnement d'interface graphique.
Voir Comment vider les tampons et le cache sur un système Linux ? pour plus de détails.
Inutilisé dans le sens :plus activement utilisé depuis une période de temps significative, la mémoire étant toujours pertinente pour ses propriétaires.
Remettre en RAM les pages stockées dans la zone de swap.
Avoir un échange aussi énorme 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 à échanger, votre système avait déjà rampé jusqu'à la mort (comme ce que vous avez vu)
Il vaut mieux utiliser zram avec une petite partition de swap de sauvegarde . De nombreux systèmes d'exploitation comme ChromeOS, Android et diverses distributions Linux (Lubuntu, Fedora) ont activé zram par défaut pendant des années, en particulier pour les systèmes avec moins de RAM. C'est beaucoup plus rapide que d'échanger sur le 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 de référence ici, il 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 un peu moins élevé. Sa vitesse de décodage est près de 5 fois plus rapide que lzo sur la base d'un benchmark officiel
En fait, Windows 10 et macOS utilisent également des techniques de compression de fichiers d'échange similaires par défaut
Il y a aussi zswap même si je ne l'ai jamais utilisé. Cela vaut probablement la peine d'essayer et de comparer celui qui convient le mieux à vos cas d'utilisation
Après cela, une autre suggestion consiste à réduire la priorité de ces processus liés aux E/S et éventuellement laisser un terminal fonctionner avec une priorité plus élevée afin que vous puissiez y exécuter des commandes immédiatement même lorsque le système est sur une charge élevée
Autres lectures
- Arch Linux - Amélioration des performances - Zram ou zswap
- Activez ZSwap pour augmenter les performances
- Activez la zRAM pour une meilleure gestion de la mémoire et moins d'échanges
- Vous manquez de RAM dans Ubuntu ? Activer la ZRAM
- Différence entre ZRAM et ZSWAP
- Zram vs zswap vs zcache Guide ultime :quand utiliser lequel
- Linux, SSD et swap
- https://wiki.debian.org/ZRam
- https://www.kernel.org/doc/Documentation/blockdev/zram.txt
- https://wiki.gentoo.org/wiki/Zram