# Postmortem: TCID-12948

> Workspace: `ws-1784858772091-b5f9b6847`
> Date: 2026-07-29
> Reviewer: evolver-bot

## Issue Summary

| Field | Value |
|-------|-------|
| Issue ID | TCID-12948 |
| Alert Type | Write latency / high-frequency small transaction write bottleneck |
| Cluster ID | loadtest-kpj |
| Cluster Type | dedicated (GCP, load test) |
| TiDB Version | unknown |
| Time Window | Load test window (exact times not specified in Jira) |

**Issue Description**: ユーザーが「100 MiB/s の TiKV 書き込み負荷でディスク拡大が有効か？」を質問。実際の根因は TiKV CPU 飽和（13/21 ノードが 80–96%）による高頻度小トランザクション書き込みパスのボトルネック。ディスクは副次的寄与に過ぎなかった。AutoChat タイムアウト（190s）で診断が完了せず、ユーザーが「分析が完了しませんでした」とフィードバック。

## Actual Root Cause

> Human-confirmed root cause from Jira resolution, oncall handoff, or expert analysis.

TiKV 全ノードの CPU 飽和による 2PC RPC ボトルネック。具体的には：
- INSERT 1行/クエリ × ~5,300/s + UPDATE × ~3,466/s（バッチなし）
- 高頻度小さい 2PC トランザクション → TiDB→TiKV への大量 RPC
- TiKV gRPC スレッドプール CPU 飽和（db-tikv-11: 95%、db-tikv-5: 96%、計 13/21 ノードが 80–96%）
- db-tikv-11 の resolve_lock latch wait P99 = 19.14s（ベースライン < 0.02s）
- storage async write P99: db-tikv-11 で 7.32s（ベースライン < 0.07s の 100 倍超）
- COMMIT slow log 184,537 件（平均 2.67s、最大 25.03s）

ディスク書き込みは GCP PD 200GiB の上限（~120-240 MB/s）にピーク時接近（144-165 MB/s）したが、write stall = 0 で CPU 飽和が先行している。

## Agent Diagnosis Summary

> What the Agent concluded (final answer from unguided first attempt).

Replayer が postmortem workspace（ws-1784858772091）で診断を実行。60 tool call（59 completed / 1 failed）。

1. **Jira コンテキスト読み込み**: Fujishima さんの内部コメントを含む TCID-12948 の詳細分析を取得
2. **collect_evidence.py 実行**: tidb-clinic-diagnosis collect_evidence.py が正常実行完了、gate_checks.json・evidence_summary_for_agent.txt・metrics.json 生成
3. **追加メトリクス収集**: clinic-cli を使用して TiKV 書き込みパス特有のメトリクス（gRPC 負荷、prewrite/commit P99、storage async write P99、resolve_lock latch wait、disk write bytes）を詳細収集
4. **インスタンス別分析**: store-to-instance マッピングを使って db-tikv-11 / db-tikv-5 を特定
5. **正しい根因**: TiKV CPU 飽和 + 高頻度小トランザクション 2PC ボトルネックとして正確に診断

**注記**: TopSQL（Delta Lake 路径不存在 HTTP 500）は取得不可。ユーザーが報告した AutoChat タイムアウト（ws-1784789403368, ISS-0114）は別の workspace セッションでの問題で、このポストモーテム用 workspace は replayer が手動で作成・完了したもの。

## Scores

| Dimension | Score (1-5) | Notes |
|-----------|-------------|-------|
| Root Cause Accuracy | 5 | TiKV CPU 飽和 + 2PC RPC ボトルネックを正確に特定、原因候補（write stall、disk、RocksDB）を全て否定済み |
| Evidence Completeness | 4 | metrics + activity hub + clinic-cli で詳細分析。TopSQL は Delta Lake 不可で欠落（ISS-0057）、slow query logs も未取得 |
| Causal Chain | 5 | INSERT/s → 2PC RPC 増大 → gRPC CPU 飽和 → scheduler backlog → storage async write P99 上昇 → COMMIT slow log の完全な因果連鎖 |
| Actionability | 5 | INSERT バッチ化（1→100行で RPC 1/100）、UPDATE 最適化、ディスク拡大タイミング、容量計画まで具体的に提示 |
| Efficiency | 3 | 60 tool call / 1 failed（write_analyst_report.py パス不一致、ISS-0113）。ユーザー介入なし。Jira コメントを活用した効率的な分析 |
| **Overall** | **4.4** | |

## Human Guidance Log

なし（replayer による完全自動診断、ユーザー介入ゼロ）。

ユーザーが見た実際の体験は ws-1784789403368（AutoChat タイムアウト 190s、ISS-0114）での診断未完了。

## Skill Deficiencies

### D1: write_analyst_report.py パス不一致（tidb-perf-diagnosis vs tidb-clinic-diagnosis）

- **Type**: TOOLING
- **Skill**: `tidb-perf-diagnosis`
- **Current behavior**: 最終レポートマージ時に `tidb-clinic-diagnosis/scripts/write_analyst_report.py` を参照するが、このワークスペースは `tidb-perf-diagnosis` スキルを使用しているためパス不一致で 1 tool call failed
- **Expected behavior**: アクティブな skill ディレクトリのスクリプトを動的に参照すべき（fallback パスは成功しているため影響軽微）
- **Suggested fix**: ISS-0113 参照
- **Priority**: P2-medium
- **Status**: ISS-0113 として追跡中

### D2: TopSQL 不可用（Delta Lake パスなし）

- **Type**: TOOLING
- **Skill**: `tidb-clinic-diagnosis`
- **Current behavior**: A4 段で HTTP 500（Delta Lake table not found）、TopSQL データ欠落
- **Expected behavior**: TopSQL 不可の場合、診断出力に明確に「TopSQL データ不可（データパイプライン問題）」と記載
- **Suggested fix**: ISS-0057 参照
- **Priority**: P2-medium
- **Status**: ISS-0057 として追跡中

## Key Queries

### TiKV CPU per instance（clinic-cli PromQL）

```
rate(tikv_thread_cpu_seconds_total[5m])
```

### TiKV storage async write P99

```
histogram_quantile(0.99, rate(tikv_storage_engine_async_request_duration_seconds_bucket{type="write"}[5m]))
```

### TiKV gRPC command latency（prewrite P99）

```
histogram_quantile(0.99, rate(tikv_grpc_msg_duration_seconds_bucket{type="kv_prewrite"}[5m]))
```

### Resolve lock latch wait P99

```
histogram_quantile(0.99, rate(tikv_storage_latch_wait_duration_seconds_bucket{type="resolve_lock"}[5m]))
```

## Lessons Learned

- **高頻度小トランザクションは 2PC RPC ファンアウトで TiKV CPU を飽和させる**: INSERT 1行/クエリ × 5,300/s はそれぞれ 2PC prewrite+commit RPC を発生させ、21 TiKV ノード全体に分散しても CPU を飽和させる。バッチ化（100行/クエリ）で RPC 数を 1/100 に削減できる。
- **ディスク拡大は主因ではない**: write stall = 0、CPU 飽和が先行している場合、ディスク拡大のみでは COMMIT 遅延は解消しない。CPU ボトルネックを先に解消すべき。
- **AutoChat 190s タイムアウトは複雑な診断を完了させられない** (ISS-0114): planning + evidence collection + synthesis 合計 300-400s に対して 190s は不十分。