对我们而言，影响性能最大的一些配置参数与写回节流有关（因为我们使用 NVMe 日志）。问题是节流启动得太早了。结果，日志能够吸收更多的负载，但被备份 HDD 强制减慢了速度。您可以（但不应该）完全关闭 wb_throttling，因为这可能会在以后导致巨大的峰值和减速，因为 HDD 将无法跟上 NVMe SSD 的速度。
调整 CPU
Ceph 的经验法则是，您需要的 CPU 核心数与节点中的 OSD 数量相同。此后，仅核心时钟速度才算数。当谈到 CPU 时钟速度时，您应该注意 CPU 状态，即C 状态。您可以根据功耗来调整它们。
选择正确的 IO 调度程序
Linux 内核有多个 IO 调度程序。每个调度程序在不同工作负载下提供不同的性能。对于 Ceph，您应该使用 deadline 调度程序。
RAID 控制器
在为 Ceph 集群构建硬件时，如果要使用 RAID 控制器，则需要考虑 RAID 控制器。每个 RAID 控制器都有不同的属性。有些控制器比其他控制器消耗更多的 CPU，这意味着 Ceph 操作所需的 CPU 周期更少。Ceph的基准测试很好地证明了这一点。
调整底层文件系统
文件系统也应进行相应配置
使用 XFS 作为 OSD 文件系统，并采用以下推荐选项。
其他硬件组件
我们的第一个 Ceph 集群仅使用 SSD，节点有 24 个独立 OSD。基准测试很快显 土耳其 电话号码 示某个地方在 24 Gbps 处存在瓶颈，但 LSI HBA 的吞吐量为 48 Gbps。深入研究服务器的构建方式以及驱动器的连接方式后发现，瓶颈在于 SAS 扩展器，因为驱动器与其的连接方式不同。
内核客户端与 FUSE 客户端
我们最初的部署使用了 FUSE Ceph 客户端，因为它支持文件系统配额和闪电般的文件和目录大小报告。这是通过跟踪每个文件操作的元数据服务器实现的（不同于传统文件系统，每次需要时都必须计算目录大小）。话虽如此，FUSE 的速度还是慢得令人无法接受。
让我们看些简单的基准
由于此存储用于共享托管平台，我们认为 WordPress 部署 当你参加这些活动时 速度是一个很好的基准。使用 FUSE 客户端，在我们的 CephFS 文件系统上提取和部署 WordPress 平均需要 30 秒。相比之下，使用内核客户端最多需要 2 秒。
FUSE 客户端平均需要 40 秒才 电子邮件列表 能提取 Drupal。使用 Kernel 客户端最多需要 4 秒。
另一个快速基准测试最后我们根据自己 涉及提取 Linux 内核。使用 FUSE 客户端，在 CephFS 文件系统上提取 linux-4.10.tar.xz 平均需要 4 分钟。使用内核客户端，最多需要 30 秒。