機能のスタックに基づいたデバイス/dev/mydisk
があります。LUKSで暗号化されたソフトウェアRAID-1です。
時々、/dev/mydisk
の内容をLUKSを使用して暗号化されている外部USBディスクにバックアップします。 100のカップルGiBを転送する必要があります。この操作は単純なdd
ではなく、再帰的なcp
(rsync
を使用するように変更する必要があります)
バックアップの開始後しばらくすると、システム全体の対話性が大幅に低下します。 KDEインターフェースが窒息死し、メモリ要求が許可されるのを待っているようです。プロンプトが2分間待機するのは珍しいことではありません。同様に、ネットワークI/Oを待つことは、多くの忍耐を必要とします。これは、baloo
が起動してすべてのZipを解凍し、不明な目的ですべてのファイルコンテンツにインデックスを付けることを決定した場合と同様の動作です。システムは沼地のカヌーになります。
カーネルがすべてのRAMをコピープロセスに与えており、インタラクティブプロセスにチャンスを与えるためにそれを返すことを嫌っています。RAMは粗末ではありません: 23 GiB。また、念のため、11 GiBのスワップ領域がありますが、いつでもいくつかのMiBによって占有されています。
対話型プロセスがコピープロセスよりもRAMを優先して取得することを確認できますか?可能な場合、どのようにですか?
バージョン情報:
これまでの答えをありがとうございました!
何を検索するかがわかると、いくつかのことがわかります。
私が何を手に入れたか:
dd
を使用しているため、救済策はフラグoflag=direct
を使用してページキャッシュをバイパスすることです。なぜ今までにI/Oチューニングを処理するエキスパートシステムがないのですか?
検索しましたが、ドキュメントには記載されていませんが、nocache
書き込みでは正しく機能するはずです 。小さなファイルをコピーする場合、各ファイルでfdatasync()
呼び出しが必要になるため、実行速度は遅くなります。
(Linux固有の機能を使用すると、多数のfdatasync()
/fsync()
呼び出しの影響を軽減できます。 dpkg
は機能します。IO and cache effects に関するこの関連する回答では、nocache
を変更してclose()
を延期する必要があり、これは状況によっては望ましくない副作用があります:-(。)
別のアイデアは、おそらくsystemd-run
を使用してcgroupでコピープロセスを実行し、メモリ消費量に制限を設定することです。 cgroupメモリーコントローラーは、キャッシュとプロセスメモリーを制御します。 systemd-run
コマンドの良い例が見つかりません(たぶん誰かが提供してくれるでしょう:-)。
Nice -n 19
バックアッププロセス(CPUに低い優先度を与える)、そしておそらくionice -c 3
(アイドル時のI/O)。
rsyncも大幅に改善されます(毎回100Gbをコピーしません)。たとえば、私のバックアップスクリプトは次のようになります。
SOURCE=/whatever/precious/directory
DESTINATION=/media/some_usb_drive/backup
Nice -n 19 rsync --verbose --archive --compress --delete --force --recursive --links --safe-links --rsh ssh --exclude-from=$EXCLUDEFILE $SOURCE $DESTINATION
# or
Nice -n 19 ionice -c 3 rsync --verbose --archive --compress --delete --force --recursive --links --safe-links --rsh ssh --exclude-from=$EXCLUDEFILE $SOURCE $DESTINATION
(exclude-fromは、.cacheディレクトリ、.oファイルなどを回避するために使用されます)