以下是根據 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 取得針對您環境的客製化告警規則。
評估總結：對方建議整體保守且緊扣官方文件，適合「生產穩定優先」環境；我的前次建議則更積極針對 Bare Metal 高寫重 OLTP（70% Write、100k QPS、低 P99）進行實戰微調。兩者互補，可結合使用。
以下逐任務比較，標註優點、差異與我的推薦調整（基於 2.20.4 + Bare Metal 48C/750GB/NVMe）。
任務一：配置優化
記憶體與快取
對方建議：
--use_memory_defaults_optimized_for_ysql=true（正確，官方 YSQL 首選）。db_block_cache_size_percentage（預設 -1000 自動）。我的前次建議：
memory_limit_hard_bytes設 500-550GB（留 OS/Postgres 緩衝）。db_block_cache_size_percentage55-60%、global_memstore_size_percentage15-20%。比較與推薦：
use_memory_defaults_optimized_for_ysql=true，再用memory_limit_hard_bytescapping 在 520-580GB（避免 OOM Killer）。併發與連線管理
對方：強推 YSQL Connection Manager (YCM)（內建、多執行緒、無 PgBouncer 的 SQL 限制），
ysql_conn_mgr_max_client_connections=10000、worker_threads=CPU/2。正確且現代。我：建議 PgBouncer/Odyssey 同節點 Transaction mode。
比較與推薦：
儲存、Thread Pool、Raft
對方：
rocksdb_max_background_compactions預設依 CPU（>32 core → 4 threads）。我：priority_thread_pool_size 16-24、rate limit 提高至 2-4GB/s、heartbeat 可調 200-300ms（測試）。
比較與推薦：
priority_thread_pool_size至 12-20 與 rate limit 至 2-3GB/s。Raft heartbeat 調低需極謹慎（多機櫃環境網路 jitter 風險高），預設 500ms 已足夠，除非 P99 寫延遲是 SLA 瓶頸且測試穩定。整體任務一結論：對方更貼官方，我更偏實戰效能。最佳實踐 = 對方基礎 + 我的 workload 微調（先用 smart defaults + YCM，再 load test 調 cache/MemTable/compaction）。
任務二：擴容時機
對方：
我：
比較與推薦：
任務三：PromQL 與 Alerting
對方：提供多個官方 YBA Alert Policy Templates（CPU、OOM、disk usage 等），非常實用。
我：提供自訂 Node Exporter + YB metrics（如 P99 histogram、RPC queue）複合條件。
比較：
最終建議矩陣（綜合兩者）
use_memory_defaults_optimized_for_ysql=true+ YCM + 官方 CPU/Disk alert。memory_limit_hard_bytescapping、MemTable 比例、priority compaction pool（load test 驗證）。對方建議適合「穩健合規」路線，我的則偏「極致效能」。在 Bare Metal OLTP 下，兩者結合後再 load test 驗證 是最佳做法。您目前 gflags 設定與關鍵 metrics（Memory Breakdown、Tablet count、P99）若能提供，我可給更精準的 delta 調整。需要完整 Ansible + Prometheus rules YAML 嗎？