以下是根據 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 取得針對您環境的客製化告警規則。
這份建議其實「相當接近官方 recommended baseline」，而我前面提供的則比較偏：
兩者並不衝突，但層級不同。
你可以理解成：
類型 | 定位 -- | -- 官方文件導向建議 | Safe baseline 我前面的建議 | 高壓 OLTP tuning strategy四、max_connections
官方：
48 cores：
我前面：
其實：
沒有衝突
因為：
官方是：
upper recommended bound
我的是：
low-latency conservative bound
高 QPS OLTP 真相
backend 多：
不一定 throughput 高。
很多時候：
因為：
LWLock contention
scheduler thrashing
cache miss
NUMA bounce
會開始出現。
我現在會修正成：
建議範圍
然後：
五、Compaction Threads
這裡是兩份建議差異最大的地方。
官方
這是：
非常保守的 safe baseline
目的：
避免：
compaction 自己吃掉 CPU
我前面：
這其實是：
哪個對？
答案：
兩個都對
但 workload 不同。
官方配置適合：
你的 workload：
這是：
真正 production 經驗
如果 compaction thread 太少：
你會看到：
接著：
write latency 飆升
flush stall
WAL backlog
RPC queue 堆積
我現在會給你的折衷建議
不要直接 16。
建議：
然後觀察：
compaction pending bytes
CPU system%
disk await
再決定要不要到 12~16。
六、Raft heartbeat
這部分：
官方與我：
幾乎完全一致。
結論
不要亂改：
是正確的。
七、真正重要：官方文件沒講，但 production 非常重要的東西
這些是我認為：
比 gflags 更重要的
1. NUMA
750GB RAM：
很可能：
如果：
IRQ
compaction thread
memory allocation
跨 NUMA：
P99 會非常醜。
建議
至少：
或者：
CPU pinning。
2. IRQ balancing
10Gbps：
+
100k QPS
network IRQ 很可能成為：
system CPU bottleneck。
3. Filesystem
XFS 通常比 ext4 更適合：
RocksDB
大量 compaction
4. THP
官方常常輕描淡寫。
但 production：
八、我的最終建議（融合版）
這是我認為你現在最適合的方向。
第一階段（官方 baseline）
Compaction：
YCM：
先 PoC
不要直接 production 全切
第二階段（壓測後）
根據：
compaction debt
P99 latency
RPC queue
tablet density
再決定：
memstore override
block cache override
compaction threads increase
我認為你現在最需要監控的 Top 5 指標
這比所有 gflags 更重要：
Top 1
Top 2
Top 3
Top 4
Top 5
這五個會比：
CPU%
RAM%
更早告訴你：