以下是根據 YugabyteDB 官方文件中可查證的資訊所提供的技術建議。對於文件未涵蓋的細節，我會明確標示。
--memory_limit_hard_bytes / --default_memory_limit_to_ram_ratio
官方強烈建議在 YSQL 環境下啟用以下旗標，讓系統自動依節點 RAM 大小最佳化記憶體分配：
--use_memory_defaults_optimized_for_ysql=true
此旗標會自動設定記憶體分區比例，並強制執行 Tablet 數量上限。以您 750 GB RAM 的節點為例，依官方文件的參考表格（256 GiB 節點最高支援 22,100 tablet replicas），750 GB 節點的承載量遠超過此值，但實際數字需依運行時計算。[Deployment checklist]
Tablet Replica 的記憶體開銷基準：
- 每 1000 個 tablet replicas 基本開銷：800 MiB
- 加計快取等使用後，官方建議預留：7,000 MiB / 1000 tablet replicas [Deployment checklist]
db_block_cache_size_percentage
預設值為 -1000，表示系統會根據可用 RAM 自動決定建議百分比。官方不建議手動覆蓋此值，除非有特定需求。[All YB-TServer flags]
注意： 文件未提供針對 OLTP 場景的 block cache vs. MemTable 精確比例建議值，此部分需依實際 workload 監控調整。
--ysql_max_connections
預設值為自動計算（最低 50，最高 300 per node）。官方建議：
# 依節點 vCPU 數量，建議後端實體連線數：
# 10–15 physical connections per vCPU
# 48 core node -> 480–720 backend connections (保守~激進)
面對 2000 個活躍連線與 100K QPS，官方強烈推薦使用內建的 YSQL Connection Manager（YCM），而非外部 PgBouncer，理由如下：[YSQL Connection Manager]
| 比較項目 | PgBouncer | YSQL Connection Manager |
|---|---|---|
| 架構 | 單節點/進程 | 多執行緒，隨 CPU 核心擴展 |
| SQL 限制 | 不支援 TEMP TABLE、SET 等 | 無此限制 |
| 部署方式 | 需獨立部署或多實例 | 內建於 TServer，無需額外部署 |
相關配置旗標：
--ysql_conn_mgr_max_client_connections=10000 # 預設值
--ysql_conn_mgr_worker_threads=<CPU_cores / 2>
Compaction 執行緒數：
--rocksdb_max_background_compactions 預設為 -1（自動依 CPU 核心數計算）：
- ≤4 cores → 1 thread
- ≤8 cores → 2 threads
- ≤32 cores → 3 threads
- >32 cores → 4 threads
您的 48 core 節點預設為 4 threads。如需提升 compaction 速度，可透過 priority_thread_pool_size 旗標調整。[yb-tserver configuration]
WAL 刷盤速率：
--rocksdb_compact_flush_rate_limit_bytes_per_sec=1073741824 # 預設 1 GB/s
針對 100K IOPS 的 NVMe SSD，可考慮提高此值，但官方文件指出預設值為強烈建議，調整前應先確認 compaction 是否成為瓶頸。
Raft Heartbeat：
--raft_heartbeat_interval_ms 預設 500ms。官方文件未建議在標準 OLTP 場景下降低此值；降低可能增加 Raft 流量開銷。對於 Read Replica 環境，文件建議將 --leader_failure_max_missed_heartbeat_periods 提高至 10。[yb-tserver configuration]
根據 YugabyteDB 官方文件，以下是建議的告警閾值：
| 指標 | Warning 閾值 | Severe 閾值 | 說明 |
|---|---|---|---|
| CPU 整體使用率 | >70%（持續 5 分鐘） | >90%（持續 5 分鐘） | 高 CPU 可能需要 Yugabyte Support 協助除錯 [Performance metrics] |
| Memory 使用率 | >70% | >90% | 不建議直接對 memory 告警，應追查底層問題 [Performance metrics] |
| Disk 使用率（空間） | 剩餘 <40% | 剩餘 <25% | 通常在 80% 使用率時考慮擴容 [Performance metrics] |
| Clock Skew | >500ms | — | 超過此值系統可能拒絕啟動或崩潰，應列最高優先處理 [Performance metrics] |
注意： 知識來源中未提供 CPU iowait 與 NVMe Disk I/O Latency (await) 的具體建議閾值，此部分無法從現有文件中確認。
根據官方文件，應定期監控以下 YugabyteDB 內部指標：
| 指標 | 監控位置 | 說明 |
|---|---|---|
| P99 Read/Write Latency | YSQL Ops and Latency、YCQL Ops and Latency、Tablet Server > Average Latency | 依應用 SLA 調整，延遲退化時應立即調優 [YBA Performance metrics] |
| RPC Queue Size | Tablet Server > RPC Queue Size、Master Server > RPC Queue Size | Queue 積壓代表後端過載，可能引發 backpressure 錯誤 [YBA Performance metrics] |
| Remote Bootstrap | Tablet Server > Remote Bootstraps | 監控節點故障後的 bootstrap 狀況 [YBA Performance metrics] |
| DocDB Cache Hit/Miss | DocDB > Cache Hit & Miss | Cache miss 率高時需調整快取配置 [YBA Performance metrics] |
| Disk IOPS / Node | Resource > Disk IOPS / Node | 大幅飆升通常代表大型 Compaction 或 block cache miss [Performance metrics] |
| WAL Stats / Node | Tablet Server > WAL Stats / Node | 監控 log cache 的高頻率 eviction [YBA Performance metrics] |
| Reactor Delays | Tablet Server > Reactor Delays | 衡量 incoming request 的瓶頸 [YBA Performance metrics] |
重要限制： 知識來源中未提供 P99 延遲的健康基準線數值，也未提供 Tablet 數量與 CPU 核心數的「黃金比例」建議值。這些數值需依實際 workload 特性與官方 Yugabyte Support 確認。
以下 PromQL 直接參考官方 Alert Policy Templates 文件中的查詢語法。
CPU 整體使用率（對應官方 DB node CPU usage 模板）：
# 告警：任意節點平均 CPU 使用率持續 30 分鐘超過 90%
count by (node_prefix) (
(
100
-
(
avg by (node_prefix, instance) (
avg_over_time(
irate(node_cpu_seconds_total{job="node",mode="idle",node_prefix="$node_prefix"}[1m])[30m:]
)
)
*
100
)
)
>
90
)
節點下線偵測（持續 15 分鐘）：
count by (node_prefix) (
max_over_time(up{export_type="node_export",node_prefix="$node_prefix"}[15m]) < 1
)
>
0
節點 OOM Kill 偵測：
count by (node_prefix) (yb_node_oom_kills_10min{node_prefix="$node_prefix"} > 1) > 0
節點非預期重啟偵測（30 分鐘內）：
max by (node_prefix) (changes(node_boot_time{node_prefix="$node_prefix"}[30m])) > 0
Disk 資料分區使用率：
count by (universe_uuid) (
count by (universe_uuid, node_name) (
100 - (
sum without (saved_name) (node_filesystem_free_bytes{mountpoint=~"__mountPoints__",universe_uuid="__universeUuid__", fstype!="rootfs"})
/
sum without (saved_name) (node_filesystem_size_bytes{mountpoint=~"__mountPoints__",universe_uuid="__universeUuid__", fstype!="rootfs"})
* 100
) > __threshold__
)
)
File Descriptors 使用率（超過 70%）：
count by (universe_uuid) (ybp_health_check_used_fd_pct{universe_uuid="$uuid"} > 70)
根據官方文件中可查證的閾值，建議以下複合條件作為啟動擴容規劃的觸發標準：
| 層級 | 條件 | 對應官方閾值 | 建議動作 |
|---|---|---|---|
| Warning | 任意節點 CPU 使用率 > 70%，持續 5 分鐘 | 官方 Warning 閾值 | 調查 workload，準備擴容評估 |
| Severe | 任意節點 CPU 使用率 > 90%，持續 5 分鐘 | 官方 Severe 閾值 | 立即聯繫 Yugabyte Support，啟動擴容採購 |
| Severe | 任意節點 Memory 使用率 > 90% | 官方 Severe 閾值 | 追查底層問題（不直接對 memory 告警），評估擴容 |
| Critical | 任意節點 Disk 剩餘空間 < 25% | 官方 Severe 閾值 | 立即擴容或清理資料 |
| Critical | OOM Kill 發生次數 > 1（10 分鐘內） | 官方模板 | 立即介入，評估記憶體配置與節點擴充 |
| Critical | Clock Skew > 500ms | 官方建議 | 最高優先修復，可能導致系統拒絕啟動 |
| Informational | RPC Queue Size 持續積壓 | 官方建議監控 | 評估是否需要增加節點分散負載 |
重要說明： 知識來源中未提供 P99 Read/Write Latency 的 PromQL 查詢語法，也未提供 YB-TServer RPC Queue 等待時間的具體 PromQL。上述矩陣僅包含官方文件中有明確數值依據的條件。如需完整的 YugabyteDB 內部指標 PromQL，建議參考 YugabyteDB Anywhere Alert Policy Templates 的完整頁面，或聯繫 Yugabyte Support 取得針對您環境的客製化告警規則。
以下內容我會以「YugabyteDB on Bare Metal、高併發 OLTP、低 P99 latency、可預測 scale-out」為核心目標來設計。
你目前這組硬體其實已經接近「中大型 OLTP 叢集」等級：
6 nodes
RF=3
48 physical cores / node
750GB RAM
100k IOPS SSD
10Gbps
100k QPS peak
70% write workload
這類 workload 的真正瓶頸通常不是：
CPU 不夠
記憶體不夠
而是：
Raft write pipeline
RocksDB compaction debt
WAL fsync latency
RPC queue saturation
Tablet 過度碎片化
Context switching
PostgreSQL backend connection explosion
所以 tuning 的核心方向會是：
壓低 write amplification
降低 compaction backlog
避免 thread contention
控制 tablet density
避免 YSQL backend 爆炸
維持 predictable latency
一、Bare Metal OLTP 的 YugabyteDB 配置優化
1.1 TServer 記憶體配置策略
你的機器：
750GB RAM
Bare metal
幾乎 dedicated
不建議：
把記憶體全丟給 YugabyteDB
因為：
Linux page cache
compaction buffer
kernel slab
TCP buffer
filesystem metadata
jemalloc fragmentation
都需要 headroom。
建議配置
memory_limit_hard_bytes
建議：
約：
580GB 給 YB
170GB 留給 OS
這是非常安全的 OLTP 配置。
不要超過：
82~85% physical RAM
否則：
compaction spike
page reclaim
direct reclaim
kernel stall
會讓 P99 爆炸。
1.2 Block Cache vs MemTable
OLTP 70% write：
你真正怕的是：
flush storm
compaction storm
不是 cache miss。
因此：
不要把 block cache 拉太大。
建議比例
RocksDB Block Cache
約：
145GB block cache
非常夠。
MemTable
建議提高：
32GB memtable pool。
目的：
減少 flush frequency
拉長 immutable memtable 週期
降低 compaction pressure
OLTP 最佳實踐比例
大致：
Component | Ratio -- | -- Block Cache | 20~30% MemTable + write buffer | 5~10% OS Free + FS cache | 20~25% Other internal memory | 剩餘1.3 避免 OOM Killer
務必要：
以及：
THP 不關：
latency jitter 會非常明顯。
1.4 YSQL max_connections
你有：
2000 active connections
但：
YSQL 是 PostgreSQL process model。
每個 backend：
memory
scheduler
LWLock
context switch
都很重。
強烈建議
不要：
建議：
真正 active backend：
控制在 300~500
其餘交給 pooler。
1.5 PgBouncer / Odyssey 部署位置
建議：
「同節點 sidecar-ish deployment」
也就是：
每個 application AZ：
部署 local PgBouncer pool
而不是：
centralized pool cluster
不建議獨立 pool cluster
原因：
會增加：
cross-rack RTT
TCP congestion
TLS overhead
queue jitter
最佳實踐
Application node：
PgBouncer mode
OLTP：
1.6 shared_buffers
YugabyteDB：
shared_buffers 不需要像 PostgreSQL 那麼大。
因為：
真正 cache 在 RocksDB。
建議
已經很大。
不要超過：
64GB
否則：
NUMA contention
allocator fragmentation
反而增加 latency。
1.7 Compaction / Storage tuning
Compaction threads
你的 SSD 很強：
100k IOPS
所以：
compaction threads 可以拉高。
建議
SST file size
OLTP：
不要太大。
否則：
compaction latency 長
write amplification 高
建議
並保持：
避免：
gigantic SST。
WAL
最重要。
建議
不要關。
但：
1MB sync batching。
降低 fsync pressure。
1.8 Raft heartbeat
不要亂調太低。
很多人會誤會：
heartbeat 越低 latency 越好。
實際上：
會造成：
RPC storm
CPU interrupt storm
leader instability
建議
維持：
除非：
跨 DC
WAN
否則不建議調。
1.9 Tablet 數量
這是最重要的 scale 指標之一。
建議 tablet density
每 node
建議：
你是：
48 cores。
黃金比例
超過：
通常：
compaction
Raft
scheduler
RPC queue
會開始失控。
二、Scale-out Trigger 指標
2.1 OS 層級
CPU
User CPU
健康：
警戒：
危險：
持續 15 分鐘。
System CPU
重要。
高 system CPU：
通常代表：
mutex contention
network IRQ
context switch
storage interrupt
建議
就要調查。
iowait
NVMe 正常情況：
應極低。
建議
健康：
警戒：
危險：
Disk await
OLTP：
非常重要。
建議
Read await：
Write await：
如果：
代表：
compaction debt
queue congestion
開始形成。
2.2 DB Latency 基準
Point Lookup
健康：
很好：
Write latency
健康：
很好：
危險訊號
如果：
持續 10~15 分鐘。
通常：
代表：
compaction saturation
raft queue congestion
WAL bottleneck
2.3 RPC Queue
這是 Yugabyte 真正的 early warning。
健康
RPC queue wait：
警戒：
危險：
三、PromQL 與 Alert Rules
3.1 CPU 飽和
CPU 使用率
Alert
3.2 CPU iowait
Alert
3.3 NVMe await
Read await：
Write await：
Alert
3.4 P99 Read Latency
YB metrics 名稱可能依版本略不同。
通常：
P99 Write
3.5 Active Connections
Alert
3.6 RPC Queue Wait
或：
依版本不同。
Alert
四、真正的 Scale-out Trigger Matrix
這才是最重要的。
不要：
單一 metric scale out
會誤判。
建議複合條件
Level 1（容量規劃）
觸發條件：
→ 開始採購。
Level 2（需於 1~2 週內擴容）
→ 安排新增 node。
Level 3（危險）
→ 緊急 scale-out。
五、你這組硬體的實際 OLTP 上限（經驗值）
以：
RF=3
NVMe 100k IOPS
48 cores
6 nodes
合理 tuning 下：
保守穩定區
P99 可維持：
極限區
通常：
compaction debt
RPC queue
WAL sync
會開始失控。
最後的核心建議
你目前真正應該優先做的，不是再調 gflags。
而是：
第一優先
建立：
tablet density dashboard
compaction backlog dashboard
RPC queue dashboard
第二優先
限制：
active backend 數量
這通常比：
CPU tuning
heartbeat tuning
重要十倍。
第三優先
建立：
「Latency degradation before saturation」
模型。
因為 Yugabyte：
不是 CPU 100% 才壞。
而是：
這才是 scale-out 真正應該監控的訊號。