☰

Samba 和 luks 加密磁盘一起使用：尽管 CPU 资源充足，但性能损失巨大，单独使用 LUKS 和 samba 可以正常工作

tag-icon • tag-icon performance samba cpu-usage performance-tuning luks
Samba 和 luks 加密磁盘一起使用：尽管 CPU 资源充足，但性能损失巨大，单独使用 LUKS 和 samba 可以正常工作

设置：使用 luks aes-xts 512 位（256 位 AES 密钥）加密的 SSD，ext4 文件系统

dd 写入的表演138 MB/秒，CPU使用率97-100％

dd if=/dev/zero of=testfile status=progress bs=32M count=128
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31 s, 138 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 31,0463 s, 138 MB/s

dd 读取表现110 MB/秒，CPU 使用率一开始为 90% 以上，然后下降到 50-60% 左右，然后在文件读取结束时再次上升到 90% 以上。

#crop cache before
sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"

现在做测试：

dd if=testfile of=/dev/null status=progress bs=32M
4261412864 bytes (4,3 GB, 4,0 GiB) copied, 39 s, 109 MB/s
128+0 Datensätze ein
128+0 Datensätze aus
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 39,1345 s, 110 MB/s

现在让我们仔细看看 samba：

写作1 GB 文件到桑巴上述磁盘基准测试的共享给出了73 MB/秒，CPU占用率只有70%左右。

阅读一个 1 GB 的文件桑巴分享仅提供关于64 MB/秒，CPU 使用率约为 55%。另请观察此图：它开始时很慢，然后速度时快时慢，形成某种波形。

在此处输入图片描述

立即再次复制此文件，当它处于缓存，然后将其复制112 MB/秒，因此可以达到应有的千兆以太网速度。

相比于未加密的驱动器：

dd 写入速度133 MB/秒

dd 读取速度207 MB/秒

Samba 写入：112 MB/s

Samba 读取：112 MB/s

因此，仅使用 LUKS 加密即可提供足够的速度，仅使用 Samba 也具有足够的速度。 组合起来，性能会大幅下降，但仍然有足够的 CPU 资源可供单独使用 dd 时使用。

这里出了什么问题？为什么在使用 dd 时执行 samba 操作时 CPU 没有得到充分利用？如何才能在 smb 和 luks 加密时获得最佳性能/CPU 使用率？

答案1

我对此进行了更深入的探讨。

这看起来像是 CPU 使用率的错误显示。

使用 Samba 从未加密的驱动器读取，速度为 112 MB/s，整个系统的 CPU 使用率约为 38% CPU 使用率约为 38%

从未加密的驱动器读取时，CPU 使用率在 29% 之间浮动，有时甚至会迅速上升至 94%。

现在将加密读取性能从 110 MB/s 降低 38% 得到 68.2 MB/s。这与 64 MB/s 非常接近。

因此从逻辑的角度来看：Samba 本身需要相对较多的 CPU，并且结合加密，产生的速度现在似乎是合理的。

顺便说一句：进行这些测试的系统是 Rasperry PI 400，配备 4 核 arm CPU，默认时钟频率为 1.8 GHz。cryptsetup benchmark报告显示，对于具有 512 位密钥（即 256 位 AES 加密）的 aes-xts，加密速度为 77 MB/s，解密速度为 66.9 MB/s。但是 cryptsetup 只使用一个 CPU 进行这些测试，所以我猜电源管理会降低 CPU 的时钟频率，这就是为什么真正的加密和解密性能会像 dd 所示的那样好得多。

我还做了一些其他性能测试。

我还将 /dev/mapper 和 /dev/sdd 上的预读大小从 256 增加到了 65536 sudo blockdev --setra 65536 /dev/sdd，sudo blockdev --setra 65536 /dev/mapper/sdd_crypt然而这并没有带来任何明显的区别。

深入挖掘后，我发现了这篇非常有趣的文章https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

他们的研究始于no_read_workqueue内核no_write_workqueue版本 5.9。幸运的是，当前的 Rasperry PI OS 是 5.10.11-v7l+，因此 dmcrypt 支持这些选项。

但是 Raspberry PI OS Buster 上最新的 cryptsetup 版本 2.1.0 不支持这些选项。因此，我编译了 cryptsetup 2.3.4 以使用 no_read_workqueue 和 no_write_workqueue（请参阅 https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-crypt.html）并通过安装

cryptsetup open --perf-no_read_workqueue --perf-no_write_workqueue /dev/sdd sdd_crypt

但是，当从设备而不是 RAM 磁盘读取时，此特定设置的性能会大大降低。

总之：由于最终的速度是合理的，因此 CPU 使用率的显示似乎是错误的。

相关内容