☰

問題

tag-icon • tag-icon encryption luks
問題

問題

最近、i7-6820HQ、32GB の RAM、512GB Micron 1100 SSD を搭載した Lenovo T460p に Ubuntu 16.04 LTS (カーネル 4.8.0-52) をインストールしました。インストール中にフルディスク暗号化ボックスをオンにし、デフォルトのパーティション レイアウトを使用しました。全般的に、パフォーマンスは良好です。

しかし時間が経つにつれて、ビルドの実行に 2 倍ほどの時間がかかるようになりました。さらに、ビルドの大きなファイルを書き込む部分では、ディスク I/O を必要とする (ビルド以外の) タスクは、長時間待機することになります。これには、新しいプログラムの起動、Firefox でのページの読み込みなどが含まれます。たとえば、Firefox では、UI をナビゲートしたり、タブを切り替えたりすることはできますが、すべて問題ありません。しかし、リンクをたどると、状況が落ち着くまで UI 全体がロックされます。

まとめると、しばらくするとビルドにかかる時間が突然長くなり、ビルド中の特定の時点ではコンピューターが基本的に使用できなくなります。

この問題を診断または解決するにはどうすればよいでしょうか?

トラブルシューティング情報

  • 頻繁に再起動しないので、この問題が発生するまで数日間システムが稼働していることがよくあります。この問題が発生すると、問題の原因を突き止めようとしばらく手探りした後、再起動して作業を続行します。

  • この問題を解決する唯一の方法は、マシンを再起動することです。すべてのアプリケーションを終了し、ログアウトして再度ログインし、バッファ キャッシュを削除してみましたが (メモリ領域が使用されるにつれてディスク同期がより頻繁に発生するという仮説)、再起動するしかありませんでした。

  • とりあえず、私は解決策を試しましたこの答えしかし、行動に変化はありませんでした。

  • 実行中は、問題が発生しているときはいつでも、スレッドが99%のI/Oを使用していることiotopがわかります。dmcrypt_writeないこの問題が発生すると、比較的高い IO % でトップにポップが表示されますがdmcrypt_write、その状態は長く続きません。

  • dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync正常に動作しているときに実行すると、 dmcrypt_write1、2 秒間最上部にジャンプしますが、ビルド中と同じ期間にはほど遠いです。

  • フルビルドでは約 1.4 GB のデータが生成されます。これは複数のモジュールを含む Java プロジェクトです。そのため、多数の小さなファイルと、それらの小さなファイルすべてを集約したいくつかの大きな JAR ファイルが作成されます。

  • 使用可能なメモリは常に十分あり、スワップ パーティションは使用されていません。

  • 同僚にも同じようなコンピューター（T460p）を使っていて、Ubuntuも使っているが、この問題は発生していない。彼らは全員同じ問題を抱えているようだ。違うただし、SSD のブランド/モデルは異なります。

アップデート

問題が再び発生したため、この質問への返信に基づいてさらにテストを実施しました。

  • ファイルシステムはまだdiscardオプションでマウントされていないので、代わりにオプションを有効にfstrimした場合と多少似ていると想定して実行しました。discard
  • 問題が最初に発生したときに十分なタイミングをとっていませんでした。しかし、を実行した後fstrim、ビルド速度は正常に戻ったようです...しかしビルドが完了すると、dmcrypt_writeスレッドが起動し、システムが一定期間使用できなくなります。全体として、ビルドにかかる時間とシステムが使用可能になるまでにかかる時間は、以前とほぼ同じであるようです。
  • /proc/sys/vm/dirty_ratio2 と 1 に変更して/proc/sys/vm/dirty_background_ratio、ビルドをいくつか実行しました。ビルドには通常よりも時間がかかりました。この問題に遭遇した前回とほぼ同じですが、システムがロックされることはそれほど多くないようです。20 と 10 に戻すと、上記の動作に戻りました。
  • クリーン ブートで、/proc/sys/vm/dirty_ratio2 と/proc/sys/vm/dirty_background_ratio1 に設定してみましたが、時間は 20 と 10 の場合とほぼ同じでした。

答え1

Debian 10+11 でも同様の問題が発生しました。LUKS ディスクに大量の書き込み操作を行うと、システム全体がしばらくフリーズし、その後再び応答し、またフリーズするという問題がありました...

ただし、再起動する必要はありません。書き込み操作が完了するまで待つだけです。

ScumCoder が書いたように、修正が利用可能です。カーネル 5.9 以降、修正はカーネルに統合されています。

次のコマンドで問題は解決しました:

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

次のコマンドを使用してディスク名「nvme0n1p3_crypt」を抽出しました。dmsetup table

私はインスピレーションを得たhttps://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

修正後、書き込み操作が大幅に高速化されました。

答え2

私もあなたとまったく同じ問題を抱えており、簡単に調べたところ、次の投稿が見つかりました:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

CloudFlare の従業員は Linux ソース コードを徹底的に調査し、現在の実装に原因があると結論付けましたdmcrypt。彼は基本的にカーネルの対応する部分を書き直すことで問題を解決しました。

したがって、私の知る限り、速度低下を解消する唯一の方法は、(1) 彼のバージョンのカーネルをコンパイルするか、(2) 時々再起動する (あなたが言ったように) ことです。私は後者を選択しました。

答え3

LUKS については詳しくありませんが、SSD の一般的な IO の問題については、fs マウントの破棄がオンになっていることを確認してください。つまり、grep 破棄 /proc/mounts を実行するか、(root として)「echo 1 >> /proc/sys/vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio」を試してみてください。これにより、書き出すデータのバックログが少なくなると、システムはより早く IO を開始します。

関連情報