☰

問題

tag-icon • tag-icon encryption luks
問題

問題

我最近在配備 i7-6820HQ、32GB RAM 和 512GB Micron 1100 SSD 的 Lenovo T460p 上安裝了 Ubuntu 16.04 LTS（核心 4.8.0-52）。我在安裝過程中選取了全碟加密方塊並使用了預設的分割區佈局。總的來說，性能很棒。

然而，隨著時間的推移，我的建置開始運行的時間大約是原來的兩倍。此外，在寫入大檔案的建置部分期間，任何需要磁碟 I/O 的（非建置）任務最終都會等待很長時間。這包括啟動新程式、在 Firefox 中載入頁面等。但如果我點擊一個鏈接，整個用戶界面就會鎖定，直到事情平靜下來。

總而言之，在一段時間之後，構建突然需要更長的時間，並且在構建過程中的某些時刻計算機基本上無法使用。

我可以做什麼來嘗試診斷或解決此問題？

故障排除訊息

  • 不要經常重新啟動，因此在我遇到此問題之前系統通常會運行幾天。一旦我擊中它，我就會嘗試找出問題所在，然後重新啟動，以便我可以繼續工作。

  • 解決該問題的唯一方法是重新啟動機器。我嘗試退出所有應用程序，註銷並重新登錄，並刪除緩衝區快取（連枷理論，因為它使用內存空間，磁碟同步發生得更頻繁），但只有重新啟動才有效。

  • 作為一個遠景，我嘗試了解決方案這個答案但行為沒有改變。

  • 每當我遇到問題時，運行iotop都會顯示線程使用 99% I/O。dmcrypt_write當我不是遇到這個問題時，我還看到dmcrypt_write以相對較高的 IO % 彈出到頂部，但它不會在那裡停留很長時間。

  • 如果我dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync在一切正常工作時運行，dmcrypt_write將會跳到頂部一兩秒，但它的持續時間與我的一個構建期間的持續時間相差甚遠。

  • 完整建置會產生約 1.4 GB 的資料。這是一個包含多個模組的 Java 專案。因此，會建立許多小檔案以及一些聚合所有這些小檔案的較大 JAR 檔案。

  • 始終有足夠的可用內存，並且交換分區未被使用。

  • 我的同事使用類似的計算機 (T460p) 也運行 Ubuntu，但沒有遇到此問題。他們似乎都有不同的不過，SSD 品牌/型號。

更新

這個問題又出現了，所以我根據這個問題的回覆做了一些更多的測試。

  • 文件系統仍未使用該discard選項安裝，因此我運行假設這與啟用該選項fstrim有點相似discard
  • 當問題第一次發生時，我沒有做足夠的計時，但運行後fstrim，構建速度似乎恢復正常...但建置完成後，dmcrypt_write線程啟動並使系統在一段時間內無法使用。建置系統以及系統變得可用的所有總時間似乎與以前大致相同。
  • 我更改/proc/sys/vm/dirty_ratio為 2 和/proc/sys/vm/dirty_background_ratio1 並運行了一些建置。建置花費的時間比正常情況要長，與我上次遇到此問題時的時間大致相同，但係統似乎沒有那麼多鎖定。將其更改回 20 和 10 會恢復到上述行為。
  • 在乾淨啟動時，我嘗試設定/proc/sys/vm/dirty_ratio為 2 和/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-加密

CloudFlare 員工對 Linux 原始碼進行了大量挖掘，得出的結論是罪魁禍首是目前的dmcrypt實作。他基本上是透過重寫內核的相應部分來解決這個問題的。

因此，據我所知，擺脫速度緩慢的唯一兩種方法是（1）編譯他的內核版本，或（2）偶爾重新啟動一次（正如您所說）。我選擇了後者。

答案3

不具體了解LUKS，但對於SSD 上的一般IO 問題，請確保您的fs 掛載啟用了丟棄，即grep Discard /proc/mounts 也可能會嘗試（以root 身份）“echo 1 >> /proc/sys / vm/dirty_background_ratio; echo 2 >> /proc/sys/vm/dirty_ratio"，這將使系統在待寫出的資料較少時更快地啟動 IO。

相關內容