FoundationDB 性能评估报告

[yangyang233333]

FoundationDB 性能评估报告

1. 测试环境

1.1 集群规模

• 3 节点 FoundationDB 集群（3 台物理机，互为对等）
• FoundationDB 版本：7.3.77（storage engine: ssd-redwood-1）
• 冗余模式：double，Coordinators：3
• 每机部署 32 个 fdbserver 进程，全集群共 96 个进程（进程编排见 1.3）

1.2 单机硬件配置（每节点一致）

项目	规格
CPU	2 × Intel Xeon Silver 4310 @ 2.10GHz（睿频 3.30GHz），共 24 物理核 / 48 逻辑核
内存	256 GB（8 × 32GB Samsung DDR4 ECC，配置速率 2666 MT/s）
数据盘	8 × Intel SSDPF2KX076T1（7.68 TB U.2 NVMe SSD，D7-P5510 系列）
文件系统	数据盘 XFS（inode64, logbsize=32k），挂载于 /mnt/nvme0~7
操作系统	Ubuntu 22.04.5 LTS，Kernel 5.15.0

1.3 进程编排与部署配置

FoundationDB 单个 fdbserver 进程是单线程的，要充分利用多核 CPU 与多块 NVMe，需要按角色（class）拆分并显式隔离进程。基于 官方 Performance 文档「一核一进程、按角色分工」的原则，每节点编排如下（共 32 进程）：

class	数量/节点	说明
storage	24	对齐 24 个物理核，8 块 NVMe 各承载 3 个 storage 进程（datadir 分 data/data2/data3 隔离）
log (tlog)	3	WAL 写路径，分布在 3 块独立 NVMe，分摊写压力
stateless	4	承载 GRV/commit proxy、resolver、master 等无状态角色
coordinator	1	独立进程仲裁，不与 storage 混布，避免高压下 accept 队列打满导致丢 quorum

集群级配置（fdbcli> configure）：

redundancy_mode = double
storage_engine  = ssd-redwood-1
logs            = 6      # 3 节点 × 2，匹配 tlog 进程数
commit_proxies  = 6      # 写路径扩容
grv_proxies     = 6      # 读版本获取
resolvers       = 1

关键设计要点：

• class 隔离：显式为每个进程指定 class，避免 FDB 把 log/proxy/coordinator 随机塞进 storage 进程与数据读写抢占 CPU/IO。
• storage 内存上限：每个 storage 进程显式设 memory = 6GiB，防止极限压测下 32 进程 × 默认 8GiB 上限相加触发 OOM。
• coordinator 独立：coordinator 固定在独立的 stateless 进程端口上，不落在 storage 进程，保证极限压测时仲裁不受连接风暴影响。
• tester 外置：压测客户端（class=test）不部署在 FDB 节点上，改由独立的压测机集群运行，避免污染被测节点的 CPU/IO。

全集群角色分布（96 进程）：storage × 72、tlog × 6、grv_proxy × 6、commit_proxy × 3、resolver × 1、coordinator × 3、master/cluster_controller/data_distributor/ratekeeper 各 1。

2. 测试方法

• 工具：FoundationDB 官方内置压测（fdbserver -r multitest 协调器 + 多个 -c test tester）。压测客户端运行在独立压测机，不占用 FDB 节点资源，版本与集群一致（7.3.77）。
• 数据：ReadWrite workload，16B key / 100B value，每轮 60s（key 空间大小见各 workload 的 nodeCount）。
• 三类负载：

负载	参数
纯读	readsPerTransactionA=1, writesPerTransactionA=0, alpha=0
纯写	alpha=1, writesPerTransactionB=1, readsPerTransactionB=0
混合（≈91%读/9%写）	A: 10读; B: 1读9写; alpha=0.1

• 口径：transactionsPerSecond 为全局目标（分摊到所有 client），非每 client。实测应观察 Retries，若 >0 表示超发、数据失真。

3. 结果

所有结果按「测试配置」逐行记录，便于单客户端与多客户端横向对比。延迟单位 ms，TPS/QPS 为每秒事务/操作数。

3.0 并发模型说明

• client：独立的 fdbserver 进程（-c test），压测靠多 client 横向扩展。每个 client 的事务逻辑运行在单个网络线程上，故单 client 吞吐受单核限制。
• actorCount：单个 client 内并发的协程（FDB Flow 框架的 Actor）数量，在该网络线程的事件循环里协作调度。
• 总并发 = client 数 × actorCount。

3.1 纯读（point_read，每事务 1 读；key=16B, val=100B）

#	客户端数	target(全局)	actorCount	实测 TPS	事务P50	事务P90	事务P98	读P50	GRV P50	备注
1	1	12000	64	11,999	0.438	0.544	1.09	0.123	0.312	—
2	1	16000	64	15,975	0.447	0.566	1.68	0.128	0.312	—
3	1	18000	64	17,997	0.438	0.555	1.25	0.126	0.312	—
4	1	22000	64	22,004	0.447	0.566	1.35	0.133	0.312	—
5	1	32000	64	31,959	0.465	0.613	2.93	0.144	0.312	—
6	1	42000	64	42,040	0.483	0.809	5.41	0.163	0.319	—
7	1	52000	64	52,042	0.513	0.777	4.62	0.179	0.332	—
8	1	52000	128	51,978	0.513	0.704	3.65	0.176	0.332	—
9	1	62000	64	62,040	0.555	1.65	10.2	0.202	0.359	—
10	1	62000	128	61,973	0.534	0.809	5.86	0.190	0.345	—
11	1	72000	64	72,013	0.601	2.18	11.7	0.228	0.381	—
12	1	72000	128	72,014	0.601	2.22	10.6	0.223	0.381	—
13	2	100000	128	99,974	1.13	1.79	~5	0.31	0.81	单机共 2 客户端
14	5	250000	128	249,983	1.23	2.31	~14	0.33	0.88	单机共 5 客户端
15	10	500000	128	500,138	1.41	3.17	~30	0.37	1.01	单机共 10 客户端

3.2 纯写（write，每事务 1 写；key=16B, val=100B）

#	客户端数	target(全局)	actorCount	实测 TPS	事务P50	事务P90	事务P98	commit P50	GRV P50	备注
1	1	20000	64	19,966	5.2	15.2	30.3	4.53	0.63	—
2	1	20000	128	19,995	3.65	7.29	25.4	2.93	0.64	—
3	1	30000	64	30,022	4.36	15.2	29.8	3.65	0.63	—
4	1	30000	128	30,030	3.79	7.59	17.1	3.11	0.65	—
5	1	40000	64	40,075	7.29	20.0	40.8	6.6	0.68	—
6	1	40000	128	39,993	4.44	12.0	38.5	3.72	0.64	—
7	1	40000	256	39,992	5.98	12.9	32.2	5.2	0.663	—
8	1	50000	128	50,023	5.0	12.0	34.2	4.19	0.68	—
9	2	100000	128	99,667	26.4	110	195	25.4	0.88	单机共 2 客户端
10	5	250000	128	147,980	414	467	486	414	1.2	单机共 5 客户端
11	10	500000	128	146,625	845	898	916	845	1.16	单机共 10 客户端

3.3 读写混合（mixed，≈91%读/9%写，每事务约10操作；key=16B, val=100B）

#	客户端数	target(全局)	actorCount	实测 TPS	ops/s	事务P50	读P50	commit P50	Retries	备注
—										待测

4. 结论

（待补充）