以下是根據 YugabyteDB 官方文件中可查證的資訊所提供的技術建議。對於文件未涵蓋的細節，我會明確標示。

任務一：Bare Metal OLTP 配置調優

記憶體與快取分配

--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 (保守~激進)

[Right-Sizing 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>

[All YB-TServer flags]

儲存與 Thread Pool

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]

任務二：實體機環境的擴容時機評估

OS 資源臨界值

根據 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 確認。

任務三：基於 Prometheus 的 PromQL 告警規則

以下 PromQL 直接參考官方 Alert Policy Templates 文件中的查詢語法。

OS 資源瓶頸告警（Node Exporter）

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
)

[Alert policy templates]

節點下線偵測（持續 15 分鐘）：

count by (node_prefix) (
    max_over_time(up{export_type="node_export",node_prefix="$node_prefix"}[15m]) < 1
  )
>
  0

[Alert policy templates]

節點 OOM Kill 偵測：

count by (node_prefix) (yb_node_oom_kills_10min{node_prefix="$node_prefix"} > 1) > 0

[Alert policy templates]

節點非預期重啟偵測（30 分鐘內）：

max by (node_prefix) (changes(node_boot_time{node_prefix="$node_prefix"}[30m])) > 0

[Alert policy templates]

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__
  )
)

[Alert policy templates]

File Descriptors 使用率（超過 70%）：

count by (universe_uuid) (ybp_health_check_used_fd_pct{universe_uuid="$uuid"} > 70)

[Alert policy templates]

實體機擴容觸發矩陣

根據官方文件中可查證的閾值，建議以下複合條件作為啟動擴容規劃的觸發標準：

層級	條件	對應官方閾值	建議動作
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 Bare Metal OLTP 極致效能優化與擴容體系架構建議報告

1. 背景資訊 (Context)

1.1 基礎架構與硬體規格 (每台實體節點)

部署環境：Bare Metal (Ansible 自動化部署)
拓樸架構：6 節點, Replication Factor (RF) = 3, Multi-Rack
CPU：48 Cores
Memory：750 GB
Storage：1TB SSD (IOPS ~100k)
Network：10 Gbps
版本：YugabyteDB 2.20.4

1.2 工作負載特徵 (Workload Profile)

場景：高並發 OLTP
讀寫比：30% Read / 70% Write
查詢：Point lookups, 短交易, 高頻 UPDATE/INSERT
目標 QPS：100,000
活躍連線：2,000

2. 任務一：Bare Metal OLTP 配置優化 (Configuration Tuning)

2.1 記憶體與快取分配 (750GB RAM 佈局)

在實體機獨佔環境下，建議將 80-85% 的資源留給 YugabyteDB：

--memory_limit_hard_bytes: 建議設定為總記憶體的 80%。
- 計算：750 * 1024^3 * 0.8 = 644,245,094,400 bytes。
--db_block_cache_size_percentage: 建議維持 50% (約 322GB)。足以覆蓋極大索引與熱點數據，確保 P99 穩定。
--global_memstore_size_percentage: 針對 70% 寫入場景，建議提升至 15%，增加寫入緩衝區容忍度，減緩寫入暫停 (Backpressure)。

2.2 併發與連線管理

連線池架構：強烈建議使用專用連線池 (如 Odyssey 或 PgBouncer)。
- 部署模式：建議與 YB-TServer 同節點部署 (Sidecar)，透過 Unix Domain Socket 通訊，減少 0.1~0.2ms 延遲。
YSQL 參數：
- ysql_max_connections: 建議設為 3000。
- shared_buffers: 建議設定 4GB 即可 (數據緩存在 DocDB 層級)。

2.3 儲存與 Thread Pool 優化 (NVMe 專屬)

RocksDB Compaction：
- --rocksdb_base_background_compactions: 4。
- --rocksdb_max_background_compactions: 8。
Thread Pool：
- --priority_thread_pool_size: 48 (對應實體核心數)。
Raft 優化：
- --raft_heartbeat_interval_ms: 下調至 200ms，加速 Leader 選舉與減少抖動。

3. 任務二：實體機環境的擴容時機評估 (Scaling Triggers)

3.1 OS 資源臨界值

CPU iowait: 持續大於 5% 即視為飽和。
CPU Usage: User CPU 達到 70% 時規劃擴容，超過 85% 會造成嚴重排隊。
Disk Latency (await): NVMe 環境應 < 0.5ms，持續大於 2ms 代表 IO 瓶頸。

3.2 資料庫內部指標

P99 Latency 基準：
- Read (Point Lookup): < 2ms。
- Write (Insert/Update): < 5ms。
Tablet Density (黃金比例)：
- 建議值：每 CPU Core 負擔 10~15 個 Tablets。
- 觸發規劃：單節點 Tablet 超過 720 個 (48 * 15) 時應考慮擴容。

4. 任務三：基於 Prometheus 的告警規則與 PromQL

4.1 OS 瓶頸告警 (Node Exporter)

# 磁碟 IO 飽和度 (await > 2ms)
avg by (instance) (irate(node_disk_read_time_seconds_total[5m]) / irate(node_disk_reads_completed_total[5m])) > 0.002

# CPU 飽和度 (> 80%)
1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[15m])) > 0.8

4.2 資料庫效能劣化 (YugabyteDB Metrics)

# P99 寫入延遲 > 10ms (單位微秒)
histogram_quantile(0.99, sum by (le, instance) (rate(handler_latency_yb_tserver_TabletServerService_Write_bucket[5m]))) > 10000

# RPC Queue 等待時間 > 2ms
avg by (instance) (rate(rpc_incoming_queue_time_sum[5m]) / rate(rpc_incoming_queue_time_count[5m])) > 2000

4.3 擴容觸發決策矩陣 (Alerting Rule)

- alert: Cluster_Scaling_Required_Immediate
  expr: |
    (
      avg(1 - rate(node_cpu_seconds_total{mode="idle"}[15m])) > 0.75
      AND 
      histogram_quantile(0.99, sum(rate(handler_latency_yb_tserver_TabletServerService_Write_bucket[5m])) by (le)) > 15000
    )
  for: 15m
  labels:
    severity: critical
  annotations:
    summary: "叢集負載飽和，觸發擴容標準"
    description: "跨節點 CPU > 75% 且 P99 延遲 > 15ms，建議啟動節點擴展。"

zx1986/yb.md

Select an option

No results found

Select an option

No results found

任務一：Bare Metal OLTP 配置調優

記憶體與快取分配

併發與連線管理

儲存與 Thread Pool

任務二：實體機環境的擴容時機評估

OS 資源臨界值

資料庫內部指標

任務三：基於 Prometheus 的 PromQL 告警規則

OS 資源瓶頸告警（Node Exporter）

實體機擴容觸發矩陣

zx1986 commented May 12, 2026

Uh oh!