Ceph 和 TCMalloc 性能故事
本文只是简单地转述了最近关于 Ceph 性能的一些发现。这个故事背后的发现是近年来 Ceph 性能上最大的一次改进。因此，我将重点突出并总结这项研究，以防您不想完全阅读它。
这个故事
在 2015 年春季，两位 Sandisk 员工 Somnath Roy 和 Chaitanya Huilgol 调查并报告了许多最新 Linux 发行版中分发的 TCMalloc 版本存在的问题。在繁重的多线程内存分配工作负载下，当 TCMalloc 没有足够的线程缓存时，TCMalloc 会消耗大量的 CPU。有一个设置允许用户将线程缓存量增加到默认的 32MB 之外，但由于一个错误，这个设置直到 gperftools 的 2.2+ 版本才被忽略，而这些版本尚未打包。Sandisk 以及其他一些社区成员提供了初步的 Ceph 基准测试，表明在使用 jemalloc 或具有更高线程缓存值的较新 TCMalloc 时，性能会有所提升。最近在 2015 年 Ceph Hackathon 上，Intel 的 Jian Zhang 进一步展示了结果，表明使用 jemalloc 而不是旧版本的 TCMalloc 时，IOPS 性能提高了高达 4.7 倍。这为 Red Hat 提供了一个绝佳的机会，可以在 Ceph Hackathon 上使用 Intel 捐赠给 Ceph 社区的新性能测试集群来复制 Sandisk 和 Intel 的发现。
观察到了什么？
在小型 IO 工作负载下，JEMalloc 比 TCMalloc 2.1 快大约 4.21 倍，用于 4KB 随机写入！虽然 jemalloc 在所有测试的配置中都产生了最佳的 4KB 随机写入性能，但它也消耗了最多的内存。据估计，对于每个 OSD，jemalloc 消耗了额外的 300MB 的 RSS 和 600MB 的虚拟内存。
fio 为每个测试记录了延迟数据，但仅绘制了 4K 随机写入和随机读取的结果。在这些测试中，从 16 个 fio 进程（每个节点 2 个）发出 512 个并发 IO。在写入的情况下，由于日志写入和 3 倍复制，这导致了额外的并发性。在写入的情况下，超过 50% 的 IO 在使用 TCMalloc 2.1 时需要 20-50ms 才能完成。当使用 jemalloc 时，超过 87% 的 IO 在 10ms 或更短的时间内完成。TCMalloc 2.4 与 128MB 线程缓存显示了类似的平均改进，但整体范围更广。当 jemalloc 在 4K 随机读取测试中使用时，Ceph 能够以 2ms 或更短的时间处理 98% 的 IO。虽然这尚未达到亚毫秒延迟，但它比即使使用 128MB 线程缓存的 TCMalloc 也能获得的更接近！