zx1986/yb.md

Created May 12, 2026 15:46

Star (0) You must be signed in to star a gist
Fork (0) You must be signed in to fork a gist

Select an option

Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/zx1986/43cc70d292a718522dae065eef3be7b7.js"></script>
Save zx1986/43cc70d292a718522dae065eef3be7b7 to your computer and use it in GitHub Desktop.

Download ZIP

Raw

yb.md

以下是根據 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 取得針對您環境的客製化告警規則。

Author

zx1986 commented May 12, 2026

身為負責維護高負載系統的架構師，面對 750GB 記憶體搭配 1TB SSD 這種「大記憶體、小硬碟」的特殊硬體配置，加上高達 70% 的寫入佔比與 100,000 尖峰 QPS，系統的瓶頸極高機率會落在 WAL 的磁碟寫入延遲與 10Gbps 網路頻寬，而非讀取 I/O。

以下針對您的 Bare Metal 環境提供具體的架構調優與擴容監控方案。

任務一：針對 Bare Metal OLTP 的 YugabyteDB 配置優化

在 Ansible template 中配置 yb-master 與 yb-tserver 時，請特別留意以下參數組合：

1. 記憶體與快取分配

實體機具備 750GB 龐大記憶體，由於資料量上限僅 1TB，這意味著「熱資料幾乎可以完全載入記憶體」。

--memory_limit_hard_bytes：建議設定為實體記憶體的 80%-85%，預留約 100GB 給 OS、PgBouncer、Node Exporter 及 Ansible 相關代理程式。建議設定值為 644245094400 (約 600GB)。
--db_block_cache_size_percentage 與 --global_memtable_size_percentage：預設 Block Cache 佔比為 50%，但在 70% 高寫入佔比的場景下，過小的 MemTable 會導致頻繁的 Flush 與 Compaction，增加 SSD 磨損與 CPU 負載。
- 建議將 Block Cache 降至 40 (因記憶體絕對值夠大，240GB 的 Cache 已綽綽有餘)。
- 建議將 MemTable 比例從預設提高至 25 到 30，延緩寫入刷盤頻率。

2. 併發與連線管理

PostgreSQL 端點 (YSQL) 參數：
- max_connections：全叢集活躍連線為 2000，平均分攤至 6 個節點約 333。考量尖峰容錯，建議單節點 YSQL max_connections 設為 600。
- shared_buffers：絕對不要套用傳統 PostgreSQL 的 25% RAM 規則。在 YugabyteDB 中，資料層快取由 DocDB 的 Block Cache 負責，YSQL 的 shared_buffers 僅用於快取系統目錄 (Catalog metadata) 與暫存表。請將其設定為 512MB 或 1GB 即可，設太大反而會造成雙重快取與記憶體浪費。
連線池 (PgBouncer) 部署：
- 建議與 YB-TServer 部署在同節點 (Co-located)。在 Bare Metal 環境中，將 PgBouncer 作為本地服務執行 (監聽特定 port 並轉發至 localhost 的 YSQL port)，可以省去一次跨節點的網路跳轉 (Network Hop)。前端 Application Load Balancer 直接將流量打到各節點的 PgBouncer 即可。請配置為 Transaction pooling 模式以應對短交易。

3. 儲存與 Thread Pool

100,000 IOPS 的 SSD 足以應付一般需求，但在 70% 寫入與 RF=3 的放大效應下，需優化底層 RocksDB 參數。

Compaction 執行緒：擁有 48 Cores，可以適度增加背景工作執行緒。
- --rocksdb_max_background_compactions=8
- --rocksdb_max_background_flushes=4
WAL 策略：不建議關閉 WAL 的 fsync，但可以確認 --durable_wal_write=true (預設)。若未來 I/O 成為極度瓶頸，且應用程式能容忍毫秒級的資料遺失，才能考慮修改此項（強烈不建議）。
Raft Heartbeat (--raft_heartbeat_interval_ms)：
- 釐清觀念：Raft heartbeat 的頻率不會影響單點寫入延遲。寫入延遲取決於 Raft AppendEntries RPC 的傳輸與多數節點 WAL 刷盤的速度。
- 在同機房 10Gbps 網路下，將其從預設的 500 降至 250 或 150 的好處是：當某台實體機當機時，Leader Election 的速度會更快，減少服務中斷的微秒數；代價是背景網路雜訊與 CPU 喚醒次數增加。建議設定為 250。

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

決定 Scale-out 的時機不應只看單一指標，必須結合系統資源與資料庫內部延遲。

1. OS 資源臨界值

CPU 使用率 (User/System)：當叢集平均整體 CPU 使用率持續 15 分鐘超過 70% 時，即應準備擴容。OLTP 需要預留至少 30% 的 CPU 空間應對突發流量或節點失效時的重新平衡 (Rebalance)。
CPU iowait：若持續超過 5%，代表 CPU 正在空轉等待磁碟 I/O，這通常是 WAL 寫入達到 SSD 性能瓶頸的先兆。
NVMe Disk I/O Latency (await)：高負載下平均寫入延遲應保持在 2ms 以內。若 P99 磁碟延遲持續超過 5ms，會直接導致資料庫寫入延遲暴增。

2. 資料庫內部指標

P99 Read/Write Latency (健康基準線)：
- Read (Point Lookup)：由於記憶體極大，讀取應高度命中快取，P99 Read 應穩定在 1ms - 3ms 之間。
- Write：因 RF=3 需要網路傳輸與多數決，P99 Write 在 10Gbps 網路下應小於 8ms - 15ms。若超過 20ms 則表示有排隊現象。
Tablet 數量與 CPU 核心比例 (Per-node tablet density)：
- 黃金比例：每個實體 CPU 核心分配 8 至 24 個 Tablets。
- 以您的 48 Cores 為例，單節點 Tablet 總數建議上限為 $48 \times 24 = 1152$ 個。若單節點 Tablet 數量逼近或超過 1500 個，即使 CPU 使用率不高，Raft 群組間的 context switching 與 heartbeat 處理也會造成嚴重的底層效能損耗，此時必須擴展實體節點。

任務三：基於 Prometheus 的擴容評估與告警規則

以下提供具體的 PromQL 與複合告警規則 (適用於 Prometheus Alertmanager 配置)。

1. OS 資源瓶頸告警 (Node Exporter)

整體 CPU 飽和度 (> 70%)

100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 70

CPU iowait 異常 (> 5%)

(sum by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) 
/ 
sum by (instance) (rate(node_cpu_seconds_total[5m]))) * 100 > 5

Disk I/O 寫入延遲退化 (> 5ms)

rate(node_disk_write_time_seconds_total[5m]) 
/ clamp_min(rate(node_disk_writes_completed_total[5m]), 1) > 0.005

2. 資料庫效能劣化告警 (YugabyteDB Metrics)

註：YugabyteDB 的 latency metric 單位通常為微秒 (microseconds)，以下 15000 代表 15ms。

P99 Write Latency 劣化 (> 15ms)

histogram_quantile(0.99, sum by (le) (rate(handler_latency_yb_client_write_local_bucket[5m]))) > 15000

活躍連線數飽和度 (達最大配置的 80%)

sum by (instance) (pg_stat_activity_count{state="active"}) / 600 > 0.8

3. 實體機擴容觸發矩陣 (複合 Alerting Rule)

我們需要建立一個複合型的 Alert Rule，確保不會因為短暫的 Spike 而觸發無效告警。建議採用「硬體飽和」且同時伴隨「服務品質(延遲)下降」作為擴建決策的觸發標準。

Prometheus Alert Rule 範例 (YAML)

groups:
- name: yugabytedb_scale_out_triggers
  rules:
  - alert: OLTP_ScaleOut_Required
    expr: >
      (
        avg(100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 75
      )
      and on()
      (
        histogram_quantile(0.99, sum by (le) (rate(handler_latency_yb_client_write_local_bucket[5m]))) > 15000
        or
        histogram_quantile(0.99, sum by (le) (rate(handler_latency_yb_client_read_local_bucket[5m]))) > 5000
      )
    for: 15m
    labels:
      severity: critical
      team: devops
    annotations:
      summary: "YugabyteDB 叢集需要橫向擴容 (Scale-out)"
      description: "叢集平均 CPU 使用率持續 15 分鐘超過 75%，且 P99 寫入延遲大於 15ms 或讀取延遲大於 5ms。系統吞吐量已達硬體瓶頸，請啟動採購與擴編新節點流程。"

將這套指標整合後，您的團隊便能從「被動處理效能客訴」轉變為「數據驅動的容量規劃」。如有 Ansible playbook 中關於 PgBouncer config 渲染的細節需要討論，可隨時提出。

Author

zx1986 commented May 12, 2026

以下內容我會以「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

建議：

--memory_limit_hard_bytes=580000000000

約：

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

--db_block_cache_size_percentage=25

約：

145GB block cache

非常夠。

MemTable

建議提高：

--memstore_size_mb=32768

32GB memtable pool。

目的：

減少 flush frequency
拉長 immutable memtable 週期
降低 compaction pressure

OLTP 最佳實踐比例

大致：

1.3 避免 OOM Killer

務必要：

vm.swappiness=1
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.zone_reclaim_mode=0

以及：

transparent_hugepage=never

THP 不關：

latency jitter 會非常明顯。

1.4 YSQL max_connections

你有：

2000 active connections

但：

YSQL 是 PostgreSQL process model。

每個 backend：

memory
scheduler
LWLock
context switch

都很重。

強烈建議

不要：

max_connections=2000

建議：

ysql_max_connections=400

真正 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：

APP
 ↓
PgBouncer(local)
 ↓
YB-TServer

PgBouncer mode

OLTP：

pool_mode = transaction
max_client_conn = 20000
default_pool_size = 100
reserve_pool_size = 20

1.6 shared_buffers

YugabyteDB：

shared_buffers 不需要像 PostgreSQL 那麼大。

因為：

真正 cache 在 RocksDB。

建議

ysql_pg_conf_csv=shared_buffers=32GB

已經很大。

不要超過：

64GB

否則：

NUMA contention
allocator fragmentation

反而增加 latency。

1.7 Compaction / Storage tuning

Compaction threads

你的 SSD 很強：

100k IOPS

所以：

compaction threads 可以拉高。

建議

--rocksdb_max_background_compactions=16
--rocksdb_max_background_flushes=8

SST file size

OLTP：

不要太大。

否則：

compaction latency 長
write amplification 高

建議

--sst_files_soft_limit=48

並保持：

target_file_size_base=256MB

避免：

gigantic SST。

WAL

最重要。

建議

--durable_wal_write=true

不要關。

但：

--bytes_logged_per_sync=1048576

1MB sync batching。

降低 fsync pressure。

1.8 Raft heartbeat

不要亂調太低。

很多人會誤會：

heartbeat 越低 latency 越好。

實際上：

會造成：

RPC storm
CPU interrupt storm
leader instability

建議

維持：

--raft_heartbeat_interval_ms=500

除非：

跨 DC
WAN

否則不建議調。

1.9 Tablet 數量

這是最重要的 scale 指標之一。

建議 tablet density

每 node

建議：

600 ~ 1200 tablets / node

你是：

48 cores。

黃金比例

每 core ≈ 12~20 tablets

超過：

> 25 tablets/core

通常：

compaction
Raft
scheduler
RPC queue

會開始失控。

二、Scale-out Trigger 指標

2.1 OS 層級

CPU

User CPU

健康：

< 65%

警戒：

> 75%

危險：

> 85%

持續 15 分鐘。

System CPU

重要。

高 system CPU：
通常代表：

mutex contention
network IRQ
context switch
storage interrupt

建議

system CPU > 20%

就要調查。

iowait

NVMe 正常情況：

應極低。

建議

健康：

< 3%

警戒：

> 8%

危險：

> 15%

Disk await

OLTP：

非常重要。

建議

Read await：

< 1ms

Write await：

< 3ms

如果：

> 5~8ms

代表：

compaction debt
queue congestion

開始形成。

2.2 DB Latency 基準

Point Lookup

健康：

P99 read < 8ms

很好：

< 5ms

Write latency

健康：

P99 write < 15ms

很好：

< 10ms

危險訊號

如果：

P99 write > 25ms

持續 10~15 分鐘。

通常：

代表：

compaction saturation
raft queue congestion
WAL bottleneck

2.3 RPC Queue

這是 Yugabyte 真正的 early warning。

健康

RPC queue wait：

< 5ms

警戒：

> 20ms

危險：

> 50ms

三、PromQL 與 Alert Rules

3.1 CPU 飽和

CPU 使用率

100 - (
  avg by(instance)(
    rate(node_cpu_seconds_total{mode="idle"}[5m])
  ) * 100
)

Alert

- alert: HighCPUUsage
  expr: |
    (
      100 - (
        avg by(instance)(
          rate(node_cpu_seconds_total{mode="idle"}[5m])
        ) * 100
      )
    ) > 75
  for: 15m
  labels:
    severity: warning

3.2 CPU iowait

avg by(instance)(
  rate(node_cpu_seconds_total{mode="iowait"}[5m])
) * 100

Alert

- alert: HighIOWait
  expr: |
    avg by(instance)(
      rate(node_cpu_seconds_total{mode="iowait"}[5m])
    ) * 100 > 8
  for: 10m

3.3 NVMe await

Read await：

rate(node_disk_read_time_seconds_total[5m])
/
rate(node_disk_reads_completed_total[5m])
* 1000

Write await：

rate(node_disk_write_time_seconds_total[5m])
/
rate(node_disk_writes_completed_total[5m])
* 1000

Alert

- alert: HighDiskLatency
  expr: |
    (
      rate(node_disk_write_time_seconds_total[5m])
      /
      rate(node_disk_writes_completed_total[5m])
      * 1000
    ) > 5
  for: 10m

3.4 P99 Read Latency

YB metrics 名稱可能依版本略不同。

通常：

histogram_quantile(
  0.99,
  sum(rate(handler_latency_yb_tserver_TabletServerService_Read_sum[5m]))
  by (le)
)

P99 Write

histogram_quantile(
  0.99,
  sum(rate(handler_latency_yb_tserver_TabletServerService_Write_sum[5m]))
  by (le)
)

3.5 Active Connections

yb_ysqlserver_active_connection_total
/
yb_ysqlserver_connection_limit
* 100

Alert

- alert: YSQLConnectionSaturation
  expr: |
    (
      yb_ysqlserver_active_connection_total
      /
      yb_ysqlserver_connection_limit
      * 100
    ) > 80
  for: 10m

3.6 RPC Queue Wait

rpc_incoming_queue_time

或：

service_request_queue_time

依版本不同。

Alert

- alert: HighRPCQueueWait
  expr: |
    rpc_incoming_queue_time > 20
  for: 5m

四、真正的 Scale-out Trigger Matrix

這才是最重要的。

不要：

單一 metric scale out

會誤判。

建議複合條件

Level 1（容量規劃）

觸發條件：

CPU > 65%
AND
P99 write > 15ms
AND
tablet/core > 18
持續 7 天

→ 開始採購。

Level 2（需於 1~2 週內擴容）

CPU > 75%
AND
P99 write > 20ms
AND
RPC queue > 10ms
持續 30 分鐘

→ 安排新增 node。

Level 3（危險）

CPU > 85%
OR
iowait > 15%
OR
P99 write > 30ms
OR
disk await > 8ms
持續 15 分鐘

→ 緊急 scale-out。

五、你這組硬體的實際 OLTP 上限（經驗值）

以：

RF=3
NVMe 100k IOPS
48 cores
6 nodes

合理 tuning 下：

保守穩定區

80k ~ 120k QPS

P99 可維持：

read 5~8ms
write 8~15ms

極限區

150k~180k QPS

通常：

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% 才壞。

而是：

Latency 先惡化
→ queue 開始堆積
→ compaction debt 增長
→ tail latency 爆炸
→ cluster collapse

這才是 scale-out 真正應該監控的訊號。

Author

zx1986 commented May 12, 2026

這份建議其實「相當接近官方 recommended baseline」，而我前面提供的則比較偏：

Production OLTP extreme tuning / high-QPS operator 經驗值

兩者並不衝突，但層級不同。

你可以理解成：

類型 | 定位 -- | -- 官方文件導向建議 | Safe baseline 我前面的建議 | 高壓 OLTP tuning strategy

四、max_connections

官方：

10~15 connections per vCPU

48 cores：

480~720

我前面：

300~500

其實：

沒有衝突

因為：

官方是：

upper recommended bound

我的是：

low-latency conservative bound

高 QPS OLTP 真相

backend 多：
不一定 throughput 高。

很多時候：

400 backend
比
1200 backend
更快

因為：

LWLock contention
scheduler thrashing
cache miss
NUMA bounce

會開始出現。

我現在會修正成：

建議範圍

400~700 active backends/node

然後：

其餘 client 交給 pool

五、Compaction Threads

這裡是兩份建議差異最大的地方。

官方

48 cores -> 4 compaction threads

這是：

非常保守的 safe baseline

目的：

避免：

compaction 自己吃掉 CPU

我前面：

--rocksdb_max_background_compactions=16

這其實是：

高寫入 OLTP aggressive tuning

哪個對？

答案：

兩個都對

但 workload 不同。

官方配置適合：

一般 mixed workload

你的 workload：

70% write
100k QPS
high UPDATE/INSERT

這是：

compaction-heavy cluster

真正 production 經驗

如果 compaction thread 太少：

你會看到：

pending compaction bytes 持續增長

接著：

write latency 飆升
flush stall
WAL backlog
RPC queue 堆積

我現在會給你的折衷建議

不要直接 16。

建議：

--rocksdb_max_background_compactions=8
--rocksdb_max_background_flushes=4

然後觀察：

compaction pending bytes
CPU system%
disk await

再決定要不要到 12~16。

六、Raft heartbeat

這部分：

官方與我：

幾乎完全一致。

結論

不要亂改：

--raft_heartbeat_interval_ms=500

是正確的。

七、真正重要：官方文件沒講，但 production 非常重要的東西

這些是我認為：

比 gflags 更重要的

1. NUMA

750GB RAM：
很可能：

2-socket NUMA

如果：

IRQ
compaction thread
memory allocation

跨 NUMA：

P99 會非常醜。

建議

至少：

numactl --interleave=all

或者：

CPU pinning。

2. IRQ balancing

10Gbps：
+
100k QPS

network IRQ 很可能成為：

system CPU bottleneck。

3. Filesystem

XFS 通常比 ext4 更適合：

RocksDB
大量 compaction

4. THP

官方常常輕描淡寫。

但 production：

THP 沒關
=
P99 latency killer

八、我的最終建議（融合版）

這是我認為你現在最適合的方向。

第一階段（官方 baseline）

--use_memory_defaults_optimized_for_ysql=true
--ysql_enable_packed_row=true
--raft_heartbeat_interval_ms=500

Compaction：

--rocksdb_max_background_compactions=8
--rocksdb_max_background_flushes=4

YCM：

先 PoC
不要直接 production 全切

第二階段（壓測後）

根據：

compaction debt
P99 latency
RPC queue
tablet density

再決定：

memstore override
block cache override
compaction threads increase

我認為你現在最需要監控的 Top 5 指標

這比所有 gflags 更重要：

Top 1

pending compaction bytes

Top 2

RPC queue wait

Top 3

tablet/core

Top 4

WAL fsync latency

Top 5

P99 write latency

這五個會比：

CPU%
RAM%

更早告訴你：

cluster 即將進入 latency collapse

Author

作為資深分散式資料庫架構師與 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 可能過高導致競爭。
- 理由：TServer 需容納 Block Cache、MemTables、WAL Cache 等；OLTP 寫重需要足夠 MemTable，但不能吃掉全部 RAM。
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）

max_connections：預設 ~300 per node。2000 活躍連線 / 6 節點 ≈ 333/node，建議設 500-800（視查詢複雜度）。每連線 idle 約 6MB，活躍更高。
shared_buffers：YugabyteDB 不依賴 Postgres shared_buffers 做主要快取（用 DocDB Block Cache），保持預設或低值（25% of Postgres memory）。重點在 YB 層快取。

連線池建議：

強烈推薦 PgBouncer 或 Odyssey 部署在同節點（Bare Metal 優勢）。Transaction 模式 pooling（pool_mode = transaction），減少 YB-TServer 連線數，降低 Postgres fork 開銷與記憶體壓力。避免獨立節點（增加 hop 延遲，不利 P99）。
應用端也用 Client-side pooling + 適當 retry/backoff。

3. 儲存、Thread Pool 與 Raft

SST 檔案大小：預設合理（~2MB 左右 block）。寫重下監控 Compaction 壓力。
Compaction 執行緒：
- 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）。
WAL 刷盤：NVMe 下，fsync 相關保持預設（YugabyteDB 用 Raft WAL）。監控 WAL Cache hit。
Raft heartbeat：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）：

yb_tserver_flags:
  - memory_limit_hard_bytes: 550000000000
  - use_memory_defaults_optimized_for_ysql: "true"
  - db_block_cache_size_percentage: 55
  - global_memstore_size_percentage: 18
  - priority_thread_pool_size: 20
  - rocksdb_compact_flush_rate_limit_bytes_per_sec: 3000000000
  # raft_heartbeat_interval_ms: 250  # 測試後決定

其他系統層：ulimit 提高（nofile 64000+）、XFS + noatime、Transparent HugePages enabled、CPU governor performance。

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

OS 層級（Node Exporter）

CPU iowait：> 15-20% 持續 5-10min → I/O 瓶頸（NVMe 應很低）。
User + System CPU：整體 > 75-80% 持續 15min（48C 下留 headroom 給 Compaction/Raft）。
NVMe Disk I/O Latency (await)：讀/寫 await > 5-8ms（或 iops 接近 80% 極限）→ 告警。1TB SSD 100k IOPS 裕度大，但寫重+Compaction 易爆。

YugabyteDB 內部指標

P99 Read/Write Latency：健康基準線 讀 < 5-10ms、寫 < 10-20ms（依 SLA）。P99 > 50ms 或較 baseline 退化 2x → 調查/擴容。
Per-node Tablet Density：RF3 下，每節點 Tablet Replicas（peers）建議 500-2000（視記憶體）。每 1000 replicas ≈ 0.4 vCPU + 800MB overhead + 6.2GB 額外。48C/750GB 節點可支撐較高，但 超過 3000-4000 replicas/node 或 Tablet 過小導致管理開銷 時規劃擴容。
其他：RPC Queue 深度高、Compaction 背壓、Cache Miss 高。

黃金規則：CPU/I/O 飽和 + Latency 退化 + Tablet 密度高 = 啟動 Scale-out。

任務三：Prometheus 擴容評估與 Alerting Rules

OS 資源瓶頸告警 (Node Exporter)

# CPU iowait 激增
- alert: HighIOWait
  expr: 100 * (rate(node_cpu_seconds_total{mode="iowait"}[5m]) ) > 15
  for: 10m
  labels: severity: warning

# 整體 CPU 飽和 (user+system)
- alert: HighCPUUsage
  expr: sum(rate(node_cpu_seconds_total{mode!~"idle,iowait"}[5m])) by (instance) / count(node_cpu_seconds_total{mode="idle"}) by (instance) * 100 > 75
  for: 15m
  labels: severity: critical

# NVMe Disk Latency (await, 用 read_time / reads 等計算)
- alert: HighDiskLatency
  expr: rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) > 0.008 or rate(node_disk_write_time_seconds_total[5m]) / rate(node_disk_writes_completed_total[5m]) > 0.008
  for: 5m
  labels: severity: warning

資料庫效能劣化告警 (YB Metrics)

# P99 Latency (假設有 histogram 或用 ql_*_latency)
- alert: HighP99Latency
  expr: histogram_quantile(0.99, sum(rate(ql_read_latency_sum{...}[5m])) by (le, instance)) > 0.015 or histogram_quantile(0.99, sum(rate(ql_write_latency_sum{...}[5m])) by (le, instance)) > 0.025
  for: 5m
  labels: severity: critical

# 活躍連線飽和
- alert: HighConnections
  expr: ysql_connections_active > 600  # per node, 依 max_connections 調整
  for: 5m

# RPC Queue 等待 (高並發指標)
- alert: HighRPCQueue
  expr: sum(rpcs_in_queue) by (instance) > 100 or rpcs_in_queue_latency 高
  for: 3m

實體機擴容觸發矩陣（複合 Alert）

- alert: ScaleOutTrigger
  expr: |
    (sum(rate(node_cpu_seconds_total{mode!~"idle,iowait"}[15m])) by (cluster) / count(...) * 100 > 75)
    and 
    (histogram_quantile(0.99, sum(rate(ql_write_latency...[15m])) > 0.030) or ...read...)
    and 
    (sum(yb_tablet_replicas or tablet_peers) by (instance) > 3000)
  for: 15m
  annotations:
    summary: "多節點 CPU >75% + P99 Latency 退化 + Tablet 密度高 → 規劃新增實體節點"

實施建議：

用 group by (cluster) 或 instance 做跨節點聚合。
加入 changes() 或 predict_linear() 做趨勢預測。
Alert 後自動 Ansible + 監控 rebalance 進度。

額外 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 嗎？

Author

zx1986 commented May 12, 2026

評估總結：對方建議整體保守且緊扣官方文件，適合「生產穩定優先」環境；我的前次建議則更積極針對 Bare Metal 高寫重 OLTP（70% Write、100k QPS、低 P99）進行實戰微調。兩者互補，可結合使用。

以下逐任務比較，標註優點、差異與我的推薦調整（基於 2.20.4 + Bare Metal 48C/750GB/NVMe）。

任務一：配置優化

記憶體與快取

對方建議：

強推 --use_memory_defaults_optimized_for_ysql=true（正確，官方 YSQL 首選）。
引用每 1000 tablet replicas ≈ 800 MiB + 額外 6200 MiB（7000 MiB 總 overhead）——非常準確。
不建議輕易手動改 db_block_cache_size_percentage（預設 -1000 自動）。

我的前次建議：

memory_limit_hard_bytes 設 500-550GB（留 OS/Postgres 緩衝）。
db_block_cache_size_percentage 55-60%、global_memstore_size_percentage 15-20%。

比較與推薦：

對方更安全：smart defaults 會依節點大小自動優化 Postgres 與 TServer 比例，非常適合 Bare Metal。
我的更積極：750GB 大記憶體下，smart defaults 可能仍留過多給 Postgres（OLTP 單列查詢不需要太多 work_mem）。建議混合：開啟 use_memory_defaults_optimized_for_ysql=true，再用 memory_limit_hard_bytes capping 在 520-580GB（避免 OOM Killer）。
OLTP 寫重下，仍建議監控後微調 MemTable 比例（global_memstore 15-20%），官方雖未給精確值，但 workload 特定調整是必要。

併發與連線管理

對方：強推 YSQL Connection Manager (YCM)（內建、多執行緒、無 PgBouncer 的 SQL 限制），ysql_conn_mgr_max_client_connections=10000、worker_threads=CPU/2。正確且現代。

我：建議 PgBouncer/Odyssey 同節點 Transaction mode。

比較與推薦：

對方勝出（尤其是 2.20+ 版本）。YCM 是 YugabyteDB 原生設計，支援更多 Postgres 特性，無需額外進程。Bare Metal 強烈改用 YCM，可省掉 PgBouncer 部署複雜度。
您的 2000 活躍連線完全在 YCM 能力範圍內（搭配 client-side smart driver 更佳）。

儲存、Thread Pool、Raft

對方：

rocksdb_max_background_compactions 預設依 CPU（>32 core → 4 threads）。
WAL rate limit 預設 1GB/s 為強烈建議。
Raft heartbeat 維持 500ms，不建議調低。

我：priority_thread_pool_size 16-24、rate limit 提高至 2-4GB/s、heartbeat 可調 200-300ms（測試）。

比較與推薦：

對方較保守正確：官方預設已針對多核心優化，隨便調高 compaction threads 易搶 OLTP 查询 CPU。
我的調整適用高 IOPS NVMe：若監控顯示 compaction 背壓（SST files 多、I/O await 高），可提高 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）。

任務二：擴容時機

對方：

CPU >70% warning / >90% severe。
引用官方 tablet overhead 公式（非常好）。
無具體 P99 基準線與 tablet density 黃金比例（誠實標註）。

我：

CPU user+system >75-80%、iowait >15-20%、await >5-8ms。
P99 讀 <5-10ms / 寫 <10-20ms。
Per-node tablet replicas 建議 500-2000，超過 3000-4000 規劃擴容。

比較與推薦：

對方 CPU 閾值較保守（70%/90%），適合生產。我的 75-80% 更適合 Bare Metal 高裕度。
Tablet density：官方明確每 1000 replicas ≈ 0.4 vCPU + 7GB RAM overhead。48C/750GB 節點，安全上限約 4000-6000 replicas/node（依實際）。超過此值 + latency 退化 = 擴容訊號。
補充：結合兩者，iowait / disk await 是 Bare Metal NVMe 關鍵指標（官方文件較少提及）。

任務三：PromQL 與 Alerting

對方：提供多個官方 YBA Alert Policy Templates（CPU、OOM、disk usage 等），非常實用。

我：提供自訂 Node Exporter + YB metrics（如 P99 histogram、RPC queue）複合條件。

比較：

對方優勢：直接引用官方模板，可立即套用。
我優勢：更針對 OLTP（P99 latency、RPC queue、iowait、tablet density 複合）。
推薦：以對方官方模板為骨架，疊加我的 OLTP 特定 PromQL（High P99 Latency + High RPC Queue + CPU>75% + Tablet replicas >3000）作為 Scale-out 最終觸發。持續 15 分鐘避免誤觸。

最終建議矩陣（綜合兩者）

先套用：use_memory_defaults_optimized_for_ysql=true + YCM + 官方 CPU/Disk alert。
再微調：memory_limit_hard_bytes capping、MemTable 比例、priority compaction pool（load test 驗證）。
監控擴容：CPU >75% (15m) + P99 寫 >25-30ms + Tablet replicas/node >3500 + Disk await >6ms → 啟動新增節點。
測試流程：Staging 用 sysbench / 您的 workload 壓測前後配置，觀察 P99 與 cache miss。

對方建議適合「穩健合規」路線，我的則偏「極致效能」。在 Bare Metal OLTP 下，兩者結合後再 load test 驗證 是最佳做法。您目前 gflags 設定與關鍵 metrics（Memory Breakdown、Tablet count、P99）若能提供，我可給更精準的 delta 調整。需要完整 Ansible + Prometheus rules YAML 嗎？

Author

zx1986 commented May 12, 2026

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!

zx1986 commented May 12, 2026

Uh oh!

zx1986 commented May 12, 2026

Uh oh!

zx1986 commented May 12, 2026

Uh oh!

zx1986 commented May 12, 2026

Uh oh!

zx1986 commented May 12, 2026

Uh oh!