Jedna oprava je ujistit se, že je povolen řadič cgroup paměti (myslím, že je ve výchozím nastavení v i napůl nedávných jádrech, jinak budete muset přidat cgroup_enable=memory na příkazový řádek jádra). Poté můžete spustit svou I/O intenzivní úlohu v cgroup s limitem paměti, což také omezuje množství vyrovnávací paměti, kterou může spotřebovat.
Pokud používáte systemd, můžete nastavit +MemoryAccounting=yes a buď MemoryHigh /MemoryMax nebo MemoryLimit (záleží na tom, zda používáte cgroup v1 nebo v2) v jednotce nebo řezu, který ji obsahuje. Pokud se jedná o řez, můžete použít systemd-run ke spuštění programu v řezu.
Úplný příklad z jednoho z mých systémů pro spuštění Firefoxu s limitem paměti. Všimněte si, že toto používá cgroups v2 a je nastaveno jako můj uživatel, ne jako root (jedna z výhod v2 oproti v1 je, že delegování tohoto na uživatele bez oprávnění root je bezpečné, takže to dělá systemd).
$ 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 &
Zjistil jsem, že k tomu, aby uživatel fungoval, jsem musel použít řez. Systém jedna funguje pouze vložením možností do souboru služby (nebo pomocí systemctl set-property ve službě).
Zde je příklad služby (pomocí cgroup v1), všimněte si posledních dvou řádků. Toto je část instance systému (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
Dokumentace je v systemd.resource-control(5) .
Zdá se, že po dni nečinnosti jádro věří, že celé GUI již není potřeba, a vymaže ho z RAM (vymění ho na disk).
Jádro dělá The Right Thing™ věřit tomu. Proč by uchovával nevyužitou paměť v paměti RAM a tak ji v podstatě plýtval, místo aby ji používal jako mezipaměť nebo tak?
Nemyslím si, že linuxové jádro bezdůvodně nebo předvídatelně vyměňuje stránky, takže pokud to udělá, musí to být uložení něčeho jiného na RAM, čímž se zlepší výkon vašeho dlouhodobého úkolu, nebo alespoň s tímto cílem.
Pokud předem víte, kdy budete muset notebook znovu použít, můžete použít at příkaz (nebo crontab ), abyste naplánovali vyčištění swapu (swapoff -a;swapon -a ).
Protože čištění swapu může být přehnané a dokonce může spustit zabiják OOM, pokud se z nějakého důvodu nevejde vše do RAM, můžete prostě "odměnit" vše, co souvisí se spuštěnými aplikacemi, které chcete oživit.
Jedním ze způsobů, jak to udělat, by bylo připojit debugger jako gdb ke každému z dotčených procesů a spustit generování výpisu jádra:
# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit
Jak jste napsal, vaše dlouho běžící aplikace znovu nevyužívá data, která načte po úvodním průchodu, takže jste ve specifickém případě, kdy dlouhodobé ukládání do mezipaměti není užitečné. Dobrým řešením by pak mělo být obcházení mezipaměti pomocí přímého I/O, jak navrhuje Will Crawford.
Případně můžete pravidelně vyprázdnit mezipaměť souborů ozvěnou 1 nebo 3 na /proc/sys/vm/drop_caches pseudo-soubor, než si OS bude myslet, že je dobré vyměnit vaše GUI aplikace a prostředí.
Viz Jak vyprázdníte vyrovnávací paměti a mezipaměť v systému Linux? pro podrobnosti.
Nevyužito ve smyslu:již delší dobu není aktivně používáno, paměť je pro své vlastníky stále relevantní.
Vložte zpět stránky RAM uložené ve swapovací oblasti.
Mít v dnešní době tak obrovský swap je často špatný nápad. V době, kdy operační systém vyměnil jen pár GB paměti k výměně, se váš systém již prolezl k smrti (jako to, co jste viděli)
Je lepší použít zram s malým záložním odkládacím oddílem . Mnoho operačních systémů, jako je ChromeOS, Android a různé linuxové distribuce (Lubuntu, Fedora), po léta ve výchozím nastavení povolilo zram, zejména pro systémy s menší RAM. Je to mnohem rychlejší než vyměnit na HDD a v tomto případě jasně cítíte odezvu systému. Méně na SSD, ale podle výsledků benchmarku zde stále vypadá rychlejší i s výchozím algoritmem lzo. Můžete změnit na lz4 pro ještě lepší výkon s trochu menším kompresním poměrem. Jeho rychlost dekódování je téměř 5krát rychlejší než lzo na základě oficiálního benchmarku
Ve skutečnosti Windows 10 a macOS ve výchozím nastavení také používají podobné techniky komprese stránkovacích souborů
Je zde také zswap i když jsem to nikdy nepoužil. Pravděpodobně stojí za to vyzkoušet a porovnat, který z nich je lepší pro vaše případy použití
Poté je dalším návrhem snížit prioritu těchto procesů vázaných na IO a případně ponechat terminál spuštěný s vyšší prioritou, abyste na něm mohli okamžitě spouštět příkazy, i když je systém vytížen
Další čtení
- Arch Linux – Zlepšení výkonu – Zram nebo zswap
- Povolte ZSwap ke zvýšení výkonu
- Povolte zRAM pro lepší práci s pamětí a méně odkládání
- Dochází vám RAM v Ubuntu? Povolit ZRAM
- Rozdíl mezi ZRAM a ZSWAP
- zram vs zswap vs zcache Ultimate průvodce:kdy použít který z nich
- Linux, SSD a swap
- https://wiki.debian.org/ZRam
- https://www.kernel.org/doc/Documentation/blockdev/zram.txt
- https://wiki.gentoo.org/wiki/Zram