以下是根據 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 取得針對您環境的客製化告警規則。
作為資深分散式資料庫架構師與 DevOps 專家，我將針對您的 YugabyteDB 2.20.4 Bare Metal OLTP 環境（6 節點、RF=3、多機櫃、48C/750GB/1TB NVMe SSD/10Gbps、高並發寫重 70% 單列 Point Lookup + UPDATE/INSERT、尖峰 100k QPS、~2000 活躍連線）提供針對性優化建議。 這些建議基於官方文件、最佳實務與 OLTP 特性（低 P99 延遲、避免 OOM、I/O 效率）。
任務一：Bare Metal OLTP 配置優化 (GFlags in Ansible)
1. 記憶體與快取分配（YB-TServer 為主）
--memory_limit_hard_bytes：強烈建議明確設定，而非依賴 ratio。750GB 實體記憶體下，設定為 500-550GB（約 536870912000 ~ 590558003200 bytes）。這留給 OS + YSQL Postgres 進程 ~150-200GB 緩衝，避免 OOM Killer。預設 ratio 可能過高導致競爭。
db_block_cache_size_percentage：OLTP 讀 30% 但 Point Lookup 多，預設 50% 合理。若 Cache Miss Rate 高（監控 Memory Breakdown），可調高至 55-60%（或用
db_block_cache_size_bytes固定值）。這提升熱資料命中率，降低 P99 讀延遲。MemTable 相關（寫重 70% 關鍵）：
global_memstore_size_percentage：預設 10%，建議調高至 15-20%（寫重場景）。memstore_size_mb：預設 128MB，可依 Tablet 數調至 256MB（但注意總量受 global 限制）。global_memstore_size_mb_max：可提高至 4-6GB。其他：啟用
--use_memory_defaults_optimized_for_ysql=true（YSQL 環境推薦），它會自動優化 Postgres 記憶體分配。監控：UI 的 Memory Breakdown（BlockBasedTable、Memtables、Log Cache）與 OS
free -h/ Prometheus。2. 併發與連線管理（YSQL）
連線池建議：
pool_mode = transaction），減少 YB-TServer 連線數，降低 Postgres fork 開銷與記憶體壓力。避免獨立節點（增加 hop 延遲，不利 P99）。3. 儲存、Thread Pool 與 Raft
priority_thread_pool_size：預設 -1（依 CPU 自動），48C 環境通常夠用。可固定設 16-24（避免過度搶 CPU）。rocksdb_compact_flush_rate_limit_bytes_per_sec：NVMe 高 IOPS（100k），可提高至 2-4 GB/s（預設 1GB/s）。fsync相關保持預設（YugabyteDB 用 Raft WAL）。監控 WAL Cache hit。raft_heartbeat_interval_ms預設 500ms。OLTP 極致低延遲可調低至 200-300ms（搭配leader_failure_max_missed_heartbeat_periods調整），但會增加網路/CPU 心跳開銷。多機櫃環境需測試（10Gbps 應 OK）。預設已足夠大多數場景。YB-Master：較輕量，記憶體 ratio 保持低（~10%），重點監控 Leader 平衡。
Ansible Template 範例片段（YB-TServer）：
其他系統層：ulimit 提高（nofile 64000+）、XFS + noatime、Transparent HugePages enabled、CPU governor performance。
任務二：實體機擴容時機評估
OS 層級（Node Exporter）
YugabyteDB 內部指標
黃金規則：CPU/I/O 飽和 + Latency 退化 + Tablet 密度高 = 啟動 Scale-out。
任務三：Prometheus 擴容評估與 Alerting Rules
OS 資源瓶頸告警 (Node Exporter)
資料庫效能劣化告警 (YB Metrics)
實體機擴容觸發矩陣（複合 Alert）
實施建議：
group by (cluster)或instance做跨節點聚合。changes()或predict_linear()做趨勢預測。額外 DevOps 建議：定期 Chaos Testing（kill node）、Tablet Splitting 策略（避免過多 tablets）、定期 Major Compaction 規劃、Backup + PITR。Scale-out 時一次加 2-3 節點（RF3 平衡），讓 rebalancer 逐步遷移。
這些配置需在 staging 負載測試驗證（用 sysbench 或您的 workload）。有特定 metrics 截圖或目前 gflags 設定，我可以進一步精調。需要 Ansible playbook 範本或 PromQL dashboard JSON 嗎？