GreenNode × Lightbits PoV — BÁO CÁO BENCHMARK TỔNG HỢP

Báo cáo gộp 2 lần đo:
- Run 1 (23–24/06/2026, 1 client, baseline PoV 4.1 + max-bench) - Run 2 (29/06/2026, 3 client × 6 volume = 18 volume, 300s/test)

Cluster info: - 3× storage node (oss-nvme-01/02/03) - LightOS 3.18.2 - Mỗi node 6 NVMe data EC 4+2 + 2 journal (Samsung PM9A3 15,36TB) - AMD EPYC 9554P 64c/128t - Network bond0 2×100GbE (LACP, layer3+4, MTU 9000, single-NUMA)

Client: - Run 1: oss-nvme-04 - Run2: oss-nvme-04+05+06 - Tất cả client phần cứng, cấu hình giống như server

1. Executive Summary

Ghi nhận 3 vấn đề: 1. IOPS rất tốt — 5,44M IOPS 4K read (vượt target 36%) với latency 0,84ms avg / 2,18ms p99; đây là chỉ số quan trọng nhất cho workload database. 2. Sequential read bị limit chưa giải thích được ở ~66 Gbps/node egress — 1 client kéo 24,69 GB/s (~99% line-rate 200GbE của client), nhưng 3 client chỉ ra 27,49 GB/s (+11%). Mọi nghi phạm client-side/network/config đã loại trừ; khả năng cao limit nằm trong data-path mỗi storage node trong khi node còn ~42% CPU idle và ~65% NIC rảnh. 3. Write ở concurrency cao sụt vì GC trên ổ read-intensive — PM9A3 ~1 DWPD không phải ổ mạnh về write; hiện tượng khớp Grafana (GC BW ≈ Write BW, journal latency 60–90ms). Docs Lightbits khuyến nghị journal dùng ổ write-intensive (DWPD × size × số ổ > 80TB) — cấu hình lab chưa đạt chuẩn này.

2. Môi trường & phương pháp

Benchmark: fio libaio, direct=1, numjobs=8/job-file, runtime 600s+10s ramp (Run 1 baseline), 300s (Run 2); IOPS/BW cộng từ JSON per-volume; latency = clat.

3. Kết quả Run 1 — 1 client (baseline PoV 4.1)

4KB Random (nj8)

8KB Random (nj8)

1MB Sequential (nj8)

Nhận xét: latency 4K/8K ổn định 0,18–0,48ms, p99 <0,5ms; write sạch ở QD thấp (chưa chạm GC); CPU% là tổng tiến trình fio (gồm phần sinh tải) — overhead storage thuần thấp hơn.

Max-bench 1 client (trần một client, ngoài bảng PoV)

Xuất hiện GC trên Grafana:

1. GC BW ≈ Total Write BW — băng thông GC ngang bằng băng thông ghi của client. Nghĩa là cứ mỗi GB client ghi vào, hệ thống phải ghi thêm ~1GB nữa chỉ để dọn nhà (di chuyển dữ liệu còn sống ra khỏi các block sắp xóa). Disk đang làm việc gấp đôi — một nửa cho khách, một nửa cho việc nội bộ.

2. WA ~100% — Write amplification phản ánh lượng ghi thật xuống NAND ≈ gấp đôi lượng client gửi.

3. Journal latency 60–90ms — cho kết quả mỗi op write vào phải xếp hàng sau đám IO GC trên cùng bộ đĩa → latency write của client vọt lên.

4. CPU/mem/read-congestion ~0% — cho biết CPU không nghẽn, RAM không thiếu, đọc không tắc. Tức không còn nghi phạm nào khác — chậm không phải do thiếu tài nguyên, mà do đĩa bận dọn rác.

Ghép lại cho thấy disk đang ghi gấp đôi (1+2), khiến journal nghẽn (3) và không gì khác có lỗi (4) → GC là thủ phạm duy nhất. Có thể PM9A3 là disk read-intensive (~1 DWPD) — over-provisioning thấp, GC yếu bẩm sinh khi bị dội write dồn dập ở concurrency cao.

4. Kết quả Run 2 — 3 client × 18 volume

Phát hiện trọng tâm: trần ~66 Gbps/node

Trạng thái storage node lúc full-load sequential:

Mỗi node đứng im ở ~66 Gbps egress dù còn ~42% CPU idle, ~65% NIC rảnh, disk dư. Tăng QD ×4 (192→768 IO/client): throughput bất động (27,70→27,49), latency tăng tuyến tính (21,8→87,8ms) — loại giả thuyết thiếu QD.

Nghi phạm đã loại trừ

• NUMA (single node0, NIC cùng node)
• Version (3.18.2)
• Bond/LACP (802.3ad cả 2 link), hash layer3+4 (TX trải đều), MTU 9000 hai đầu
• Queue depth (×4 không đổi)
• Client/NIC (1 client kéo ~198Gbps)
• CPU storage (idle 42%, %soft ~1,5%)

Nghi phạm còn lại:
Giới hạn nội tại data-path duroslight per-node ở pattern sequential read — phân bổ core theo module (reader cores cố định trong system profile), pinning/shard-to-connection mapping hoặc tuning NVMe/TCP target. 16 core chạy 100% trong khi tổng CPU idle 42% gợi ý một nhóm shard cố định bão hòa chứ không phải thiếu CPU tổng.

5. So sánh chéo hai run & tính nhất quán

Điểm nhất quán đáng tin: hai bài test độc lập, cách nhau 5 ngày, cho cùng floor latency và cùng trần sequential (~24,7 vs ~27,5) → số liệu ổn định.