1 つの修正方法は、メモリ cgroup コントローラーが有効になっていることを確認することです (最新のカーネルでもデフォルトで有効になっていると思います。それ以外の場合は cgroup_enable=memory を追加する必要があります)。 カーネルコマンドラインに)。次に、メモリ制限のある cgroup で I/O 集中型タスクを実行できます。これにより、消費できるキャッシュの量も制限されます。
systemd を使用している場合は、+MemoryAccounting=yes を設定できます および MemoryHigh のいずれか /MemoryMax または MemoryLimit (cgroup v1 または v2 を使用しているかどうかによって異なります) ユニット、またはそれを含むスライス。スライスの場合は、 systemd-run を使用できます スライスでプログラムを実行します。
メモリ制限付きで Firefox を実行するための私のシステムの 1 つからの完全な例。これは cgroups v2 を使用し、root ではなく自分のユーザーとして設定されていることに注意してください (v1 に対する v2 の利点の 1 つは、これを非 root に委譲することが安全であるため、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 &
スライスを使用しなければならなかったユーザーを機能させることがわかりました。システム 1 は、オプションをサービス ファイルに入れるだけで (または systemctl set-property を使用して) 機能します。
これはサービスの例です (cgroup v1 を使用)。最後の 2 行に注意してください。これはシステム (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
ドキュメントは systemd.resource-control(5) にあります .
<ブロック引用>
非アクティブな状態が 1 日続くと、カーネルは GUI 全体が不要になったと判断し、RAM から消去 (ディスクにスワップ) したようです。
カーネルは The Right Thing™ を実行しています それを信じています。未使用のメモリを RAM に保持し、キャッシュなどとして使用する代わりに本質的に無駄にするのはなぜですか?
私は、Linux カーネルが不当に、または予期してページをスワップ アウトしているとは思わないので、そうする場合は、RAM に何か他のものを保存して、長時間実行されるタスクのパフォーマンスを向上させるか、少なくともこの目標を達成する必要があります。
ラップトップをいつ再利用する必要があるかが事前にわかっている場合は、 at を使用できます コマンド (または crontab ) スワップのクリーンアップをスケジュールします (swapoff -a;swapon -a ).
スワップのクリーニングはやり過ぎで、何らかの理由ですべてが RAM に収まらない場合に OOM キラーをトリガーすることさえあるため、復活させたい実行中のアプリケーションに関連するすべてを「スワップ解除」するだけでよいでしょう。
それを行う 1 つの方法は、gdb のようなデバッガーをアタッチすることです。 影響を受ける各プロセスに通知し、コア ダンプの生成をトリガーします。
# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit
あなたが書いたように、長時間実行されるアプリケーションは、最初のパスの後に読み取ったデータを再利用していないため、長期キャッシュが役に立たない特定のケースにいます。次に、Will Crawford によって提案されたような直接 I/O を使用してキャッシュをバイパスすることは、適切な回避策です。
または、1 をエコーして定期的にファイル キャッシュをフラッシュすることもできます。 または 3 /proc/sys/vm/drop_caches に OS が GUI アプリケーションと環境を交換することをお勧めします。
Linux システムでバッファとキャッシュを空にする方法を参照してください。 詳細はこちら
ある意味で未使用:かなりの期間以来、積極的に使用されていませんが、メモリはまだその所有者に関連しています.
スワップ領域に保存されている RAM ページに戻します。
今日、このような大規模なスワップを行うことは、多くの場合、悪い考えです。 OS がほんの数 GB のメモリをスワップするまでに、システムはすでにクロールされていました (あなたが見たように)
zram を使用することをお勧めします 小さなバックアップ スワップ パーティションを使用 . ChromeOS、Android、さまざまな Linux ディストリビューション (Lubuntu、Fedora) などの多くの OS では、特に RAM の少ないシステムでは、何年もの間デフォルトで zram が有効になっています。 ずっと速い この場合、HDD のスワップよりもシステムの応答性をはっきりと感じることができます。 SSD ではそれほどではありませんが、ここでのベンチマーク結果によると、デフォルトの lzo アルゴリズムを使用してもまだ高速に見えます。圧縮率を少し下げてパフォーマンスをさらに向上させるために、lz4 に変更することができます。デコード速度は、公式ベンチマークに基づく lzo の約 5 倍です
実際、Windows 10 と macOS も同様のページファイル圧縮技術をデフォルトで使用しています
zswap もあります 使ったことがないのに。おそらく試してみる価値があり、どちらがユースケースに適しているかを比較してください
その後、これらの IO バウンド プロセスの優先度を下げることをお勧めします。 また、システムの負荷が高い場合でもすぐにコマンドを実行できるように、端末をより高い優先度で実行したままにしておくこともできます
さらに読む
- Arch Linux - パフォーマンスの向上 - Zram または zswap
- ZSwap を有効にしてパフォーマンスを向上
- zRAM を有効にしてメモリ処理を改善し、スワッピングを減らします
- Ubuntu で RAM が不足していますか? ZRAM を有効にする
- ZRAM と ZSWAP の違い
- zram vs zswap vs zcache 究極のガイド:どちらをいつ使用するか
- Linux、SSD、スワップ
- https://wiki.debian.org/ZRam
- https://www.kernel.org/doc/Documentation/blockdev/zram.txt
- https://wiki.gentoo.org/wiki/Zram