eloqkv vs redis flex test

[liunyl]

test plan

EloqKV vs Redis Flex — 2TB Benchmark 测试方案

状态:定稿(待执行)。本方案为全新两系统对比:EloqKV(最新版)与 Redis Flex
在 2TB 数据集上各跑一遍,不复用任何历史数据。
关联 issue:#53(EloqKV vs Redis 对比落地页)。

注:测试数据集 = 2TB。Redis Flex 实例的规格上限是 3TB 容量 / 300GB RAM,
这是实例 ceiling,不是灌入量。2TB 数据装进 300GB RAM 实例 = 有效 ~15% RAM
(高于 Redis 10% 最低规则,对 Flex 略宽松——诚实标注)。Flex 价格由 300K
throughput 档决定,与数据集大小无关(2TB / 3TB 同价)。

---

0. 目标

在同一 workload 下,量化 EloqKV 与 Redis Flex 在 2TB 全随机负载下的吞吐与
深尾延迟,产出可直接写进对比页 / 成本文章的数据与图表。

核心论点(由架构决定,测试围绕它设计):

• Redis Flex = Speedb(LSM 谱系) → 读放大 + compaction stall → 尾延迟在
  带写负载下抖动。
• EloqKV = EloqStore(B-tree 变体,单 IOP/读,无 compaction) → 尾延迟随数据量与
  写比例保持平稳。

因此主战场是"带写的随机负载下的深尾延迟 + 延迟随时间的稳定性",吞吐是辅证。

---

1. 被测系统(均为最新版,全新部署)

EloqKV

• 版本:最新 release(记录确切版本号)。
• 持久化:WAL off(cache mode) —— 对齐 EloqStore 隔离 serving 延迟的口径,也与
  Flex 的 flash(非 durability)对等。
• 节点:GCP z3-highmem-14(14 vCPU / ~112GB RAM / 本地 Titanium SSD,装得下 2TB)。
  成本:$1,294/月(不含 replica;+1 replica = ×2 → ~$2,588/月)。
  ⚠️ RAM 待确认:z3-highmem-14 标配约 112GB,与早前所说 128GB 略有出入(见 §6)。
• 采集:cache 命中率、每读 IOPS(坐实 single IOP/read)、RAM 实占、节点 $/hr。

Redis Flex(已开实例,参数锁定)

• 形态:Redis Cloud(托管),引擎 Speedb。
• 实例规格上限:3TB 容量 / 300GB RAM(本测试灌 2TB)。
• 本测试有效 RAM 比例:300GB / 2TB ≈ 15%(> Redis 10% 最低;对 Flex 略宽松)。
• Max throughput 档:300K ops/sec。
• 价格:$19.64/hour ≈ $14,337/month(按 730h/月;不含 replica;+1 replica = ×2
  → ~$28,674/月);由 300K throughput 档决定,与数据集大小无关(2TB / 3TB 同价)。
• 待确认:此价是否含 HA replica、所在 region(见 §6)。
• 采集:compaction 活动、flash 读放大、cache 命中率、evictions、RAM 实占。

⚠️ 必须写进结论的 caveat

• 非同硬件:Flex 托管、机型不可控;EloqKV 自管。框架写
  "同 workload,各自跑在各自基础设施上",不写 "same hardware"。
• RAM 效率对比(强故事):同样 2TB,EloqKV 仅 ~112GB(~5.6%) 即可服务,
  Flex 用了 300GB(~15%)。结论可写:"服务同一 2TB 数据集,EloqKV 所需内存约为
  Flex 的 1/3;即便给了 Flex ~2.7 倍的内存,……"。
• 我们给了 Flex 偏宽松的 RAM(15%):Redis 文档推荐 value 的 ≥20% 留 RAM,我们的
  15% 介于 10% 最低与 20% 推荐之间——比"最低成本档"更有利于 Flex,结果不算 cherry-pick。
• 300K 是计价/SLA 上限,非随机读保证值:Flex 实测饱和吞吐 = min(300K 档,
  flash 随机读实际能力);多半远低于 300K,这本身是结论。

---

2. 公共 workload 参数

项	值	memtier flag
数据集	2TB(~8 亿 KV)	--key-minimum=1 --key-maximum=800000000
value	1–4KB 变长	--data-size-range=1024-4096 --random-data
访问	uniform random	--key-pattern=R:R
读写比	三档全测	见下
百分位	测到 P99.99	--print-percentiles 50,99,99.9,99.99
key 前缀	kv_	--key-prefix="kv_"

读写比(读:写 → memtier --ratio 即 set:get):

• 95:5 读主 → --ratio=1:19
• 50:50 平衡 → --ratio=1:1
• 5:95 写主 → --ratio=19:1

---

3. 测试矩阵(三档 mix 每档都跑完整套件)

Tier 1 —— 命根

A. 深尾延迟 @ 饱和点(300s),三档 mix

• 测到 P99.99(LSM 痛在尾部,P99 不够)。
• 重点观察 50:50 / 5:95(写越多 → compaction 越频 → 前台读尾越抖),但三档都出数。

B. 延迟随时间序列(长时 sustained run, 30–60min),三档 mix —— centerpiece 图

• 300s 聚合分位会低估 compaction stall;长时跑才跑满多个合并周期。
• 产出延迟-时间曲线:预期 Flex 周期性锯齿尖峰、EloqKV 平线。聚合数字会被质疑,
  这张图不会。时间序列采集方法见 §5。

Tier 2 —— 强支撑

C. 最大可持续吞吐(各 mix):A 的副产物,单独成表;注意对照 Flex 的 300K 档上限。

D. 成本归一化(输入已知):见 §7 成本表。Flex $14,337/月、EloqKV $1,294/月
(均不含 replica;HA 各 ×2)→ Flex ≈ 11× EloqKV。QPS-per-dollar = 实测 max QPS ÷ 月价
(待实测吞吐填入)。

E. 倾斜对照跑(Gaussian 热点),三档 mix —— 保中立,强烈建议

• 纯随机是 Flex 最坏场景;只发这个会被指"挑工况"。
• 加一组热点集可进 RAM 的倾斜负载,展示 Flex 在主场(冷热分离明确)其实没问题 →
  反而提升可信度,并给 issue Build EloqKV vs Redis comparison landing page #53 要求的 "when to choose Redis Flex" 段填实料。
• --key-pattern=G:G --key-stddev=<...> --key-median=<...>(参数见 §6 待确认)。

运行量

• A:2 系统 × 3 mix = 6 runs(各 300s)
• B:2 × 3 = 6 runs(各 30–60min)
• E:2 × 3 = 6 runs(各 300s)
• 合计 ~18 个测量 run + 并发扫描 + 各系统一次 2TB 灌数据(耗时大头) + 每块前 warm-up。

---

4. 执行步骤

Step 0 — 冒烟/校准:小数据(如 20GB)各跑一次,确认 rig、监控、指标采集链路正常,
再上 2TB。

Step 1 — 部署:按 §1 起两套系统;记录版本、节点规格、Flex 实例规格 + 价格。

Step 2 — 灌 2TB(每系统一次)

# -t16 -c4 = 64 conn → n = 8e8 / 64 = 1.25e7
memtier_benchmark -s $ip -p $port -t 16 -c 4 --ratio=1:0 --key-pattern=S:S \
  --key-prefix="kv_" --key-minimum=1 --key-maximum=800000000 \
  --random-data --data-size-range=1024-4096 -n 12500000 --hide-histogram

Step 3 — warm-up(每个测量块前):随机只读 10min 进稳态。

memtier_benchmark -s $ip -p $port -t 16 -c 16 --ratio=0:1 --key-pattern=R:R \
  --key-prefix="kv_" --key-minimum=1 --key-maximum=800000000 \
  --data-size-range=1024-4096 --test-time=600 --hide-histogram

Step 4 — A 饱和点(300s × 3 mix × 2 系统)

# 先 60s 短跑扫并发 C ∈ {8,16,32,64} 找吞吐拐点,再在拐点跑 300s 正式数:
memtier_benchmark -s $ip -p $port -t 16 -c $C_knee --distinct-client-seed \
  --ratio=$RATIO --key-pattern=R:R --key-prefix="kv_" \
  --key-minimum=1 --key-maximum=800000000 --random-data \
  --data-size-range=1024-4096 --test-time=300 \
  --print-percentiles 50,99,99.9,99.99

Step 5 — B 时间序列(30–60min × 3 mix × 2 系统):在拐点并发上加压
(--test-time=3600),同时按 §5 采集逐窗口延迟。

Step 6 — E 倾斜对照:同 Step 4,key-pattern 换 Gaussian。

Step 7 — 汇总:出表 + 图(§7)。

---

5. 指标采集(重点:采"为什么",否则结论只是 correlation)

每个 run 记录:

• memtier:最大可持续吞吐、P50/P99/P99.9/P99.99、actual throughput。
• Flex 侧(Redis Cloud 面板 / INFO):compaction 活动、flash 读放大、
  cache 命中率、evictions、RAM 实占。← 用来解释尾延迟尖峰来源。
• EloqKV 侧:cache 命中率、每读 IOPS、RAM 实占。
• 成本:两边实例 $/hr(Flex 已知 $19.64/hr;EloqKV 节点待记)。

时间序列(B 跑)采集方法 —— memtier 默认只在结束时输出聚合分位,需额外手段:

1. 旁路 latency 探针(推荐):长时主压测运行期间,另起一个低速率客户端
   (小脚本 / 第二个 memtier 限速到几百 QPS),对每个请求打时间戳 + 延迟并落日志,
   后期画延迟-时间曲线 → 干净地看出 compaction 尖峰。
2. 同时记录平台侧延迟面板(Redis Cloud latency graph;EloqKV 自带指标)按秒采样。
3. 可选:memtier --hdr-file-prefix 导出 HDR 直方图分段对比。

---

6. 待确认 / verify(动工前)

• EloqKV 节点成本 = $1,294/月(z3-highmem-14,不含 replica;HA ×2)。
• Flex $19.64/hr 不含 replica;HA ×2 → ~$28,674/月。
• EloqKV 确切版本号。
• 确认 EloqKV 节点 RAM:z3-highmem-14 标配 ~112GB,与早前"128GB"是否一致?
• Flex 实例 region;实际给的 shard 数 / vCPU。
• memtier 版本(确认 --print-percentiles、--key-pattern=G:G、
  --data-size-range 等 flag 行为)。
• 倾斜对照(E)的 Gaussian 参数:--key-stddev / --key-median 取值
  (建议热点集 ≈ RAM 容量,体现 Flex 主场)。
• 2TB key 总数按实际 value 分布微调(此处按 ~2.5KB 均值估 ~8 亿)。

---

7. 产出物(直接进对比页 / 成本文章)

表 1 — 2TB 饱和点(三档 × 两系统)

读写比	系统	Max QPS	P99 (ms)	P99.9	P99.99
95:5	EloqKV
95:5	Redis Flex
50:50	EloqKV
50:50	Redis Flex
5:95	EloqKV
5:95	Redis Flex

• 图 A:P99.99 by mix(柱状,两系统并列)。

• 图 B(centerpiece):延迟-时间曲线,每 mix 一张,Flex 锯齿 vs EloqKV 平线。

• 图 C:Max throughput by mix(标注 Flex 300K 档上限)。

• 成本表(输入已知,QPS 待实测):

  项	EloqKV (z3-highmem-14)	Redis Flex (3TB/300GB/300K)
  无 replica	$1,294/月	$14,337/月
  +1 replica(HA,×2)	$2,588/月	$28,674/月
  成本倍数	1×	~11×
  QPS-per-dollar	实测 max ÷ 月价	实测 max ÷ 月价

• 倾斜对照:random vs Gaussian 的 P99.99 对比(展示 Flex 主场表现 + EloqKV 全程平稳)。

---

附录 A — 历史 EloqStore 数据(EloqKV 2TB 为本测直接锚点)

来自 blog/2026-01-08-eloqkv-on-eloqstore/index.md 注释,read-dominant(GET)scaling:

Dataset	EloqKV QPS	EloqKV P99.99 (ms)	DRAM Redis QPS	DRAM Redis P99.99
20GB	507,012	1.551	161,910	1.431
100GB	298,712	1.431	155,415	1.511
200GB	281,433	2.031	— (超 RAM)	—
2TB	262,198	2.607	— (超 RAM)	—

→ 本测数据集正好是 2TB。历史锚点 262K 是在 z3-16(16 vCPU/128GB) 上测的;本测节点是
z3-highmem-14(14 vCPU/~112GB),核数与内存略少,新测读主预计 ~230–260K /
P99.99 ~2.6–3ms —— 略低于 262K 属正常,显著偏离才说明环境有问题。

注释里另有一段三系统(Redis/EloqKV/Kvrocks)SET/GET 延迟表(95:5/50:50/5:95),
但只有延迟、无吞吐,且未标数据集大小与百分位,与上表数值对不上(属另一组实验),
不可直接复用。

---

变更记录

• 早期设想(已废弃):复用历史 EloqKV 数据、只测 Flex;1TB;含 100K QPS 限速尾延迟测试。
• 现行:数据集 2TB,两系统全新最新版,仅饱和点,三档 mix 完整,深尾到 P99.99,
  纯随机为主 + Gaussian 对照。 EloqKV 节点 = GCP z3-highmem-14 / ~112GB / $1,294 月
  (2TB→5.6% RAM);Redis Flex 实例上限 3TB/300GB RAM(2TB→15%)/300K 档/$19.64hr。
  两者均不含 replica(HA 各 ×2)。成本:Flex ≈ 11× EloqKV。

[liunyl]

Redis Flex 2TB 测试结果（2026-06-12，Flex 侧完成）

测试脚本（模块化套件 + 编排器 + 旁路延迟探针 + 自动解析）已按本方案实现并跑完 Redis Flex 全套；EloqKV 侧待节点就位后跑同一套件。

环境与口径

项	值
Flex 实例	Redis Cloud（Speedb），Redis 8.4.0，3TB/300GB RAM/300K 档
Region / RTT	asia-northeast1（client 同 region），avg RTT 0.21ms
数据集	800,000,000 keys × 1–4KB（均值 ~2.5KB）= 1.98TB 实测 used_memory
Bench client	GCP e2-standard-8（8c/32GB），-t 8 × -c 等比放大；全程 client CPU < 34%，无污染（每 run 自动采样兜底）
灌数据耗时	2h07m @ ~180K SETs/s（64 conn）

与原方案的三处偏差（已验证/记录）

1. 灌数据 key-pattern 用 P:P 而非方案中的 S:S：实测 memtier 2.2.0 的 S:S 不按连接切分 —— 16 连接 × -n 1000、范围 16K 时 S:S 只写出 1,000 个 key（每连接重复同一序列），P:P 写出 16,000（全覆盖）。按原命令 64 连接只会灌出 ~12.5M keys（~31GB），不是 2TB。
2. 测量阶段加了 10% miss 读（后补需求）：把测量 key 范围扩到 1..888,888,888，uniform random 下 10% GET 落在不存在的 key 上；实测各 run miss 率 9.5–10%。SET 共享扩展范围，名义 miss 率随长跑缓慢下降，报告以各 run 实测 Hits/Misses 为准。
3. 拐点扫描：60s 短跑扫 c ∈ {8,16,32,64}；read/balanced 在 c=64 仍上升（取 64 并标注），write 在 c=32 出现拐点。

表 1 — 2TB 饱和点（300s @ 拐点并发，Flex 侧）

读写比	系统	Max QPS	P50 (ms)	P99 (ms)	P99.9	P99.99
95:5	Redis Flex	221,196	1.05	13.2	130	848
50:50	Redis Flex	350,504	0.84	7.3	107	210
5:95	Redis Flex	322,133（c=32）	0.37	4.7	203	210

30min 持续跑（B 项，时间序列）

读写比	持续 QPS	vs 300s	P99.9	P99.99	探针最大单次 GET	探针 >100ms 样本
95:5	220,557	≈持平	106ms	770ms	3.1s	657 / 308K
50:50	293,033	−16%	80ms	330ms	4.8s	485 / 325K
5:95	238,757	−26%	28ms	209ms	2.1s	293 / 339K

旁路探针（200 QPS 限速 GET，逐请求时间戳+延迟落 CSV）全程 0 超时；延迟-时间曲线（图 B）已出，每 mix 一张 + 三档合并对比，停顿尖峰清晰可见。

核心观察

1. 深尾命题成立：同一实例，20GB（纯内存）冒烟时 P99.99 仅 18.6ms；2TB 读主负载下 848ms，差 ~45×。30min 跑中探针抓到最长 4.8 秒的单次 GET 停顿。
2. 持续吞吐低于计费档：300K ops/s 档位，读主负载实际持续 ~220K。且 60s 短跑（410K）严重高估持续能力 —— balanced/write 的 30min 跑分别比 300s 再衰减 16%/26%，印证"聚合分位低估 stall、必须长跑"的设计。
3. 写便宜、读买单（LSM 特征）：写主 mix P50 仅 0.37ms（写路径在 RAM/append），但全场存在 ~210ms 的周期性停顿层；读越多尾越深，读主 mix 最惨。
4. 跑序 caveat：read → balanced → write 顺序执行，read 跑在 flash 缓存最冷时；balanced/write 受益于写入留下的 RAM 热值。两系统将用同一顺序，对比仍公平，但单看绝对值需注意。

执行教训

• 正式 load 前先 FLUSHALL：本次冒烟的 8M keys 与第 1 个分区重叠，flash 上覆盖写比纯插入慢 ~2×，拖了 load 尾巴 ~35 分钟。
• memtier 线程退出后进度行（ops/sec、elapsed）会冻结，只有 ops 计数器是活的。

待办

• EloqKV（z3-highmem-14）部署后跑同一套件（锚点预期 ~230–260K / P99.99 ~2.6–3ms）
• 03e 倾斜对照：--key-median/--key-stddev 待定（建议热点集 ≈ 300GB RAM）
• Redis Cloud 面板 compaction / flash 读放大截图（API 拿不到，手工）

原始数据（memtier 全量输出、探针 CSV、INFO/client CPU 采样、HDR 直方图、图 B PNG）按 run 自包含存档于测试机 ~/workspace/test_flex/results/flex/。

[liunyl]

EloqKV 1TB Benchmark Results (03c fixed-QPS + 03d load-latency)

数据集 = 1TB(400M keys × ~2.5KB),EloqKV 1.3.0,GCP 节点 172GB RAM + 2×local SSD,WAL off + data-store on,MISS_PCT=10(10% GET 打不存在的 key)。
⚠️ 这是 1TB,与上文 Redis Flex 的 2TB 数据集不同口径,不能直接按数据量对比;且 Flex 实例已删除,没有 03c/03d 对应数据。客户端为 8c,memtier -t8。

1. 固定 QPS 延迟(03c,open-loop,同 offered load)

每档 30min,旁路探针 200 QPS 采延迟。单位 ms。

读写比	目标	实测 QPS	P50	P99	P99.9	P99.99
read 95:5	100K	97,020	0.33	0.75	2.53	3.52
	150K	143,415	0.32	0.71	2.43	3.28
	200K	185,708	0.33	0.69	2.40	3.25
balanced 50:50	100K	96,507	0.21	1.30	2.03	3.60
	150K	142,499	0.22	1.06	1.80	5.02
	200K	177,626	0.22	1.12	4.42	23.04
write 5:95	100K	95,757	0.16	1.20	14.02	30.34
	150K	142,141	0.17	1.05	5.57	31.10
	200K	184,508	0.17	0.92	2.13	30.08

要点:P50/P99 全程亚毫秒~几 ms,GC 只打到 P99.9/P99.99 深尾。read 全程极平(~3ms);balanced 到 200K 出现 GC(23ms);write 三档稳定 ~30ms。

延迟-时间曲线(探针,各档一张):见分支文件 static/benchmark/issue-65/lat_fixed{100,150,200}k_{read,balanced,write}.png。

2. 负载-延迟曲线(03d,不同并发下吞吐 vs P99.99)

• read 95:5 — 平滑扩展到 367K QPS @512 并发,P99.99 全程 12–20ms,无 GC 抖动。
• balanced 50:50 — 饱和 ~340–360K QPS(384–768 并发);高并发偶发 GC 深尾(1024 并发 P99.99 2.2s)。
• write 5:95 — 峰值 ~268K QPS @64 并发,之后被 GC 压制(128+ 吞吐回落、深尾到 512 并发 4.3s)。

并发	read QPS / P99.99	balanced	write
8	37K / 24.6ms	—	68K / 10.0ms
64	235K / 6.7ms	251K / 27.9ms	268K / 33.3ms
256	347K / 20.0ms	329K / 41.0ms	147K / 198.7ms
512	367K / 12.4ms	228K / 199.7ms	249K / 4325ms
1024	—	334K / 2211ms	—

3. GC 行为(EloqStore 页回收)

GC 延迟-时间图(10s 旁路探针 GET 每窗口最大延迟)

• GC 是周期性突发:每次约 75–85 秒回收一批死页,期间 GET 延迟从 ~2ms 基线升到 16–33ms(典型),极高并发下可达 秒级(balanced 2.2s / write 4.3s),随即恢复平线。
• 由覆盖写产生的垃圾驱动:read 几乎不触发;balanced 在 ~200K 触发;write 最频繁。
• 对照 Redis Flex(2TB):compaction 锯齿是持续性的、探针峰值 3.1 秒 —— EloqKV 的 GC 抖动量级更小且偶发即恢复。

4. 内存与稳定性

• 本轮 eloqkv RSS 峰值 ~149GB / 172GB,全程有界,0 次重启。
• ⚠️ 事故记录(前一轮,默认配置):write-200K @1tb 在 177GB/无 swap 下,3 分钟内触发 353 次 compaction → 系统活锁(SSH/Redis/journald 全失联,但不是 OOM-kill、不是磁盘写满;eloqkv 进程苟活,内核无 oom 日志、盘仅 ~28% )。需手动重启,且 GCP local SSD 重启即清空 → 1TB 数据丢失。
• 配置调整后已解决:本轮(RUN#2)write-200K 顺利跑完、P99.99 仅 30ms、内存有界。

5. Caveats(诚实标注)

• 本测 1TB,Flex 是 2TB,数据量口径不同,不能直接比绝对值。
• Flex 无 03c/03d(等 QPS + 并发扫描)数据 —— 实例已删,缺对手半边;以上 EloqKV 数据为单边。
• read 03c 取自本轮重启前的归档(同 1TB、同配置、同实例)。
• ⚠️ 图表已提交到分支 benchmark/issue-65-eloqkv-1tb 下 static/benchmark/issue-65/,但本仓库是私有库,raw 链接无法在 issue 里内联渲染;上面是 blob 链接(仓库成员可点开看)。如需在 issue 里内联显示,需手动把 PNG 拖进评论框上传。

[liunyl]

补充:GC 深尾对读和写都有影响(SET vs GET 分位对比)

上一条评论的 GC 分析主要基于旁路探针(只发 GET),会低估写侧影响。memtier 对每个 run 分别报了 Sets/Gets 分位,把它们拆开看,结论修正为:GC 的 P99.99 尖峰读写都会吃,程度随 GC 严重度变化。

run(GC 受影响)	SET P99.99	GET P99.99	谁更惨
balanced 200K(轻度 GC)	5.9 ms	25.3 ms	读 ≫ 写
write 100K	19.8 ms	42.5 ms	读 > 写
write 200K	30.0 ms	31.2 ms	基本相当
03d conc=512 write(重度,~4s)	4325 ms	3949 ms	写 ≳ 读
03d conc=1024 balanced(~2s)	2228 ms	1311 ms	写 > 读

规律:

• 轻度 GC(中等负载):读受冲击明显大于写(GET 25ms vs SET 5.9ms)—— GC 的回收 IO 与读路径的 cache-miss 落盘读争资源,而写此时还能走内存缓冲。
• 重度 GC(高并发、秒级停顿):读写被打得一样惨,甚至写更惨(conc=1024 balanced 的 SET 2.2s > GET 1.3s)。GC 把存储/IO 子系统压满时,写路径(分配页/刷盘)同样被卡,SET 深尾照样飙到秒级。

注:P50/P99 不论读写仍是亚毫秒~几 ms,被 GC 抬起来的只有 P99.9/P99.99 深尾;上面是 GC 活跃窗口里的那几档。

[liunyl]

EloqKV 1TB — write-concurrency + compaction-concurrency tuning (balanced & write re-run)

Update (2026-06-17): the balanced (50:50) and write (5:95) mixes below were re-measured after adding a compaction-concurrency limit on top of eloq_store_max_write_concurrency=20. The numbers shown are this latest config; the comparison column is the previous config (write_concurrency=20 only) so the delta isolates the compaction-limit's effect. Read (95:5) was not re-run — it is GC-free and unaffected by either knob, so its earlier numbers stand. Same node (8-vCPU client, 10.146.0.11), 1TB dataset (KEY_MAX=400M, 10% miss reads), value 1024–4096B.

Caveat up front: 03c points are single 30-min runs, 03d points single 300 s runs. Tail percentiles (P99.9/P99.99) are driven by GC/compaction timing and carry real run-to-run variance — treat sub-2× differences as indicative, not statistically established.

TL;DR — adding the compaction limit clears the balanced high-concurrency throughput cliff (512 conns: 205K/270 ms → 309K/85 ms) and modestly lowers write 03c tails, but it does not fix the high-concurrency write multi-second GC stall (write@512 P99.99 still 4.49 s, ≈ 4.46 s before), and the moderate-concurrency mixed-load tails remain well above the original pre-throttle config. Memory/livelock protection is retained (peak RSS 148 GB, 0 restarts).

---

03c — fixed-QPS open-loop latency (30 min/point)

Mix	Target	Actual QPS	P50	P99	P99.9	P99.99	GET P99.99	SET P99.99	probe max	write_conc=20-only P99.99
read 95:5	100k	96,821	0.25	0.77	2.42	3.42	—	—	19	(not re-run)
read 95:5	150k	143,544	0.26	0.68	2.38	3.57	—	—	45	(not re-run)
read 95:5	200k	188,891	0.26	0.66	2.37	6.27	—	—	54	(not re-run)
balanced 50:50	100k	88,485	0.22	1.31	24.96	100.35	130.56	3.23	713	86.53
balanced 50:50	150k	132,750	0.22	1.26	14.34	56.58	73.73	4.16	872	51.46
balanced 50:50	200k	167,889	0.22	1.42	12.16	45.06	57.34	4.86	192	61.95
write 5:95	100k	94,562	0.16	1.38	14.98	62.46	143.36	18.05	208	101.89
write 5:95	150k	137,688	0.16	1.10	11.71	59.65	192.51	30.21	431	101.89
write 5:95	200k	180,416	0.17	1.10	6.46	38.40	109.57	29.82	536	48.38

(all latencies ms)

Findings (vs write_concurrency=20 only):

• Balanced (50:50): no net change — 100k/150k marginally higher, 200k lower; all within run-to-run noise. Still GET-dominated head-of-line blocking; SETs clean.
• Write (5:95): ~20–40% lower P99.99 at every tier (102/102/48 → 62/60/38 ms). Consistent direction across tiers, but single runs — suggestive, not proven.
• Relative to the original pre-throttle config (balanced 3.6/5.0/23, write 30/31/30 ms), both mixes' moderate-concurrency tails remain much higher — the throttle's read head-of-line blocking is not addressed by the compaction limit.

Latency-over-time charts: read 100k · 150k · 200k — balanced 100k · 150k · 200k — write 100k · 150k · 200k

---

03d — throughput & P99.99 vs concurrency (300 s/point, 8–512 connections)

read 95:5 (chart) — not re-run; scales clean to saturation:

conns	8	16	32	64	128	256	512
QPS	39.5K	90.7K	154.5K	235.2K	310.4K	350.1K	368.5K
P99.99 ms	4.96	3.15	2.72	3.47	8.58	10.94	11.20

balanced 50:50 (chart) — compaction-limit re-run:

conns	8	16	32	64	128	256	512
QPS	50.4K	103.1K	163.5K	230.4K	277.9K	317.7K	309.2K
P99.99 ms	9.28	16.64	30.46	48.64	57.34	74.75	84.99

The headline improvement: at 512 conns this run holds 309.2K QPS @ 85 ms, versus the write_concurrency=20-only run's throughput cliff to 204.6K @ 270 ms — the high-concurrency balanced cliff is gone. (8–256c track the prior run within noise.)

write 5:95 (chart) — compaction-limit re-run:

conns	8	16	32	64	128	256	512
QPS	46.9K	115.2K	180.1K	270.9K	215.4K	123.6K	238.8K
P99.99 ms	66.56	37.63	48.13	40.96	41.22	479.23	4489.22

Peaks 270.9K @ 64 conns. The deep tail at high concurrency is not fixed: write@256 = 479 ms, write@512 = 4.49 s — essentially unchanged from the write_concurrency=20-only run's 4.46 s (which was 202.75 / 266.24 / 4456 ms at 128 / 256 / 512).

---

GC findings (timeline chart)

• GC fired at 06:15:45Z, during the balanced-200k 03c phase (EloqStore data-file gaps as dead pages were reclaimed), and stayed active through the rest of the run — files reclaimed, no OOM, no livelock.
• Closed-loop P99.99 stays bounded at moderate concurrency, but the open-loop side-probe again caught multi-second GET stalls under heavy write+GC in 03d: 12 stalls > 1 s, peak ~5.0 s, between ~09:00–09:16 (write sweep). The worst-case write stall is still multi-second, consistent with write@512.
• Memory: peak RSS ≈ 148 GB (148,010 MB), min available 25.5 GB, 0 restarts, node responsive throughout — same protection as the write_concurrency=20-only run (149 GB).

---

Conclusion — does the compaction-concurrency limit help?

It helps in one clear place and leaves the hardest problem unsolved.

✅ Improved (vs write_concurrency=20 only):

• Balanced high-concurrency cliff eliminated — 512c 205K/270 ms → 309K/85 ms (the clearest, most structural gain).
• Write 03c tails ~20–40% lower at fixed QPS (single-run, so indicative).
• Livelock/OOM protection and bounded memory retained (148 GB, 0 restarts).

❌ Not fixed:

• High-concurrency write multi-second GC stall persists — write@512 P99.99 ≈ 4.5 s, side-probe stalls ~5 s. The compaction limit does not touch this.
• Moderate-concurrency mixed/write tails remain far above the original pre-throttle config — read head-of-line blocking from the throttle is unchanged.
• Balanced 03c unchanged (within noise).

Net: the compaction-concurrency limit is a worthwhile addition — it removes the balanced high-concurrency throughput cliff at no cost to the memory/livelock protection — but it is not the fix for the write-heavy high-concurrency deep tail, which remains ~4.5 s.

---

Caveats

• Single runs (30 min/point for 03c, 300 s/point for 03d). Tail percentiles carry real run-to-run variance; sub-2× differences (including the write 03c gains and the balanced 03c wobble) are indicative, not established — repeated runs would be needed to confirm.
• balanced & write are the compaction-limit re-run; read is from the write_concurrency=20-only run (GC-free, not re-measured).
• Single 8-vCPU client box; at ≥200k mixed QPS the client itself adds some tail.
• Charts linked as blob URLs (private repo — raw URLs don't inline-render in issues). Branch benchmark/issue-65-eloqkv-gcfix @ 4aea9759c3.
• Redis Flex 03c/03d still not run (instance deleted); this is EloqKV-vs-EloqKV.

[liangjchen]

Current EloqStore lacks IO Quality of Service (QoS), delivering unsatisfactory tail latency for write-heavy workloads. This PR fixes the issue and implements IO QoS: eloqdata/eloqstore#461.

Write tasks, including batch write tasks and compaction tasks, are background tasks in EloqStore. EloqStore is designed w/ cooperative scheduling to make sure background tasks do not interfere foreground read-only tasks. Interference comes from two sources: CPU and IO. There is already proactive CPU scheduling in place to ensure background tasks do not monopolize CPU, but there is no global IO scheduling.

Background write tasks interfere foreground read-only tasks in two ways.

1. Write tasks generate a stream of append-only, write requests, which are stripped to the device's internal channels in parallel. Processing a queue of write requests takes an exclusive ownership of a channel at a time and blocks other read requests for a period of time. The length of that blocking period depends on devices.
2. Write tasks may also generate a storm of read requests. If the device's internal queue is filled with read requests from background tasks, foreground read requests will be delayed.

To ensure IO QoS for foreground tasks, we need to restrict both 1 and 2.

1. Device write throughput is restricted, so that the device's internal blocking period is bounded when background tasks are running.
2. Background tasks' inflight read requests can only be a fraction of all inflight read requests, so that background tasks will not generate a storm of read requests, delaying foreground reads indefinitely.

What's happening before the fix:

• Batch write tasks will not generate a storm of reads, because it reads one data page, CoW it and flushes the new page to the device. So, the read and write pages are roughly 1:1.
• Compaction issues a batch (128 pages) of reads at a time. This batch is the main culprit of choking foreground reads.