主页 / server / 问题 / 1054581
Accepted
Hannes
Asked: 2021-02-23 01:19:45 +0800 CST

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

  • 772

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

dd 写入性能138 MB/s，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/s，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 文件写入samba共享大约73 MB/s，CPU 使用率仅为 70% 左右。

从samba共享中读取1 GB 文件的速度仅为64 MB/s左右，CPU 使用率约为 55%。还要看这张图：它开始缓慢，然后速度上升和下降，产生某种波形。

在此处输入图像描述

立即再次复制此文件，当它在缓存中时，它会以112 MB/s 的速度复制，因此应有全 GigabitEthernet 速度。

与未加密的驱动器相比：

dd 写入速度133 MB/s

dd 读取速度207 MB/s

Samba 写入：112 MB/s

Samba 读取速度：112 MB/s

所以单独使用LUKS加密就可以提供足够的速度，单独使用Samba也有足够的速度。结合起来，性能会大幅下降，而仅使用 dd 时仍有大量可用的 CPU 资源可用。

这里有什么问题？为什么在使用 dd 对 samba 进行操作时，CPU 没有完全使用？可以做些什么来使用 smb 和 luks 加密来获得完整的性能/CPU 使用率？

performance samba performance-tuning cpu-usage luks

1 个回答

  1. Best Answer

    我已经深入挖掘了它。

    这似乎是 CPU 使用率的错误显示。

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

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

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

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

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

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

    我还将 /dev/mapper 和 /dev/sdd 的预读大小从 256 增加到 65536 via 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 使用率的错误显示。

    • 2

相关问题