[Bug] IVF VECTOR INDEX TEST: CN OOM killed during ca_comprehensive_dataset LOAD DATA (47.29GB peak, ERROR 2013)

## Summary

Nightly regression IVF VECTOR INDEX TEST 在初始数据加载阶段（`LOAD DATA` + `INSERT SELECT` 构建 `ca_comprehensive_dataset_copy`）触发 CN 节点 OOM Killed，导致连接断开，整个 IVF 测试链路失败。

**CI Run**: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/28109604611/job/83308688825  
**Branch**: `main` | **Commit**: `a0de03067`  
**Namespace**: `mo-branch-commit-a0de03067-20260624`  
**Time Window**: 21:30 – 21:55 UTC (2026-06-24)

---

## Root Cause

CN Pod `tp-cn-4n4x7` 在执行以下语句时内存暴涨，超出 K8s 55GiB limit 被 OOM kill：

```sql
INSERT INTO anli_test.ca_comprehensive_dataset_copy SELECT * FROM anli_test.ca_comprehensive_dataset
```

触发错误：
```
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query
```

---

## Prometheus Memory Metrics

> Data source: Prometheus `container_memory_working_set_bytes` & `go_memstats_alloc_bytes`, queried from TKE Grafana (`grafana.ci.matrixorigin.cn`), namespace `mo-branch-commit-a0de03067-20260624`.

### 1. Container Memory (working_set) — All Pods

**Metric**: `container_memory_working_set_bytes{namespace="mo-branch-commit-a0de03067-20260624", container="main"}`

#### `tp-cn-4n4x7` (OOM Killed)

> ⚠️ Pre-OOM data lost（容器被 kill 后重启，旧 container 指标消失）。重启后数据如下：

| Time (UTC) | Container Memory | Note |
|---|---|---|
| 21:44:00 | **(missing)** | OOM kill 发生在此区间 |
| 21:44:30 | 0.24 GB | 容器重启中 |
| 21:45:00 | 1.08 GB | 重启完成 |
| 21:50:00 | 10.03 GB | 重新加入集群 |
| 21:55:00 | 15.89 GB | 内存再次上升 |

#### `tp-cn-lrqjc` (未 OOM，但接近 limit)

| Time (UTC) | Container Memory | Note |
|---|---|---|
| 21:30:00 | 44.86 GB | |
| 21:31:00 | **48.13 GB** ⚠️ | 峰值，距 55GB limit 仅 6.87GB |
| 21:35:00 | 41.56 GB | GC 回收 |
| 21:37:00 | 47.13 GB | 再次上升 |
| 21:40:00 | **47.97 GB** ⚠️ | 第二次峰值 |
| 21:45:00 | 38.95 GB | 数据加载阶段结束 |
| 21:55:00 | 41.39 GB | |

#### `tp-cn-25t8q` (未 OOM)

| Time (UTC) | Container Memory | Note |
|---|---|---|
| 21:30:00 | 33.01 GB | 基线 |
| 21:43:00 | 36.09 GB | 开始上升 |
| 21:45:00 | **41.61 GB** | 峰值 |
| 21:47:00 | 35.98 GB | 回落 |
| 21:55:00 | 36.76 GB | |

#### `dn-0`

| Time (UTC) | Container Memory | Note |
|---|---|---|
| 21:30:00 | 26.71 GB | 基线 |
| 21:40:00 | 28.96 GB | 开始上升（flush/compaction） |
| 21:43:00 | 33.95 GB | |
| 21:49:00 | 34.60 GB | 峰值 |
| 21:52:00 | **41.12 GB** | 二次峰值（compaction 压力） |
| 21:55:00 | 40.86 GB | |

---

### 2. Go Heap (`go_memstats_alloc_bytes`) — 堆外内存分析

**Metric**: `go_memstats_alloc_bytes{namespace="mo-branch-commit-a0de03067-20260624"}`

> 此指标仅反映 Go 堆内存（`runtime.MemStats.Alloc`），**不包含 CGO / mmap / mpool 堆外分配**。

#### `tp-cn-4n4x7` Go Heap（OOM 前）

| Time (UTC) | Go Heap | Container Memory | **Off-Heap（估算）** |
|---|---|---|---|
| 21:30:00 | 3.92 GB | (see above) | ~40 GB |
| 21:31:00 | 6.30 GB | | |
| 21:35:00 | 4.92 GB | | |
| 21:40:00 | 5.87 GB | | |
| 21:42:00 | 6.70 GB | | |
| 21:44:00 | 3.49 GB | **(OOM kill)** | |
| 21:45:00 | **0.47 GB** | 1.08 GB | 容器已重启 |
| 21:50:00 | 0.52 GB | 10.03 GB | 重启后 Go heap 极低 |

**关键发现**：`tp-cn-4n4x7` OOM 前 Go heap 仅 3~7 GB，但 container memory 达到 44~48 GB。**约 85% 的内存是堆外分配（CGO/mmap/mpool）**，GC 无法回收，这是 OOM 的直接原因。

#### `tp-cn-lrqjc` Go Heap（对比）

| Time (UTC) | Go Heap | Container Memory | Off-Heap 估算 |
|---|---|---|---|
| 21:30:00 | 8.46 GB | 44.86 GB | **~36 GB (80%)** |
| 21:31:00 | 4.82 GB | **48.13 GB** | **~43 GB (90%)** |
| 21:37:00 | **14.51 GB** | 47.13 GB | ~32 GB |
| 21:40:00 | 12.06 GB | **47.97 GB** | **~36 GB (75%)** |
| 21:44:00 | 13.17 GB | 45.25 GB | ~32 GB |
| 21:55:00 | 7.32 GB | 41.39 GB | ~34 GB |

`tp-cn-lrqjc` 同样表现出明显的堆外内存主导模式（container memory 45~48 GB，Go heap 仅 5~14 GB）。

#### `tp-cn-25t8q` Go Heap（对比）

| Time (UTC) | Go Heap | Container Memory | Off-Heap 估算 |
|---|---|---|---|
| 21:30:00 | 3.44 GB | 33.01 GB | ~29 GB (88%) |
| 21:35:00 | 7.29 GB | 33.46 GB | ~26 GB |
| 21:44:00 | **12.13 GB** | 37.86 GB | ~26 GB |
| 21:55:00 | 9.70 GB | 36.76 GB | ~27 GB |

#### `dn-0` Go Heap

| Time (UTC) | Go Heap | Container Memory |
|---|---|---|
| 21:30:00 | 5.19 GB | 26.71 GB |
| 21:40:00 | **17.08 GB** | 28.96 GB |
| 21:43:00 | **16.93 GB** | 33.95 GB |
| 21:49:00 | **18.29 GB** | 34.60 GB |
| 21:52:00 | **25.73 GB** | **41.12 GB** |
| 21:55:00 | 10.21 GB | 40.86 GB |

DN 的 Go heap 占比相对较高（21:52 达到 25.73 GB / 41.12 GB = 62%），说明 DN 的内存增长更多来自 Go 堆内的 flush/compaction 缓冲。

---

### 3. OOM Kill Confirmation (kube-state-metrics)

**Metric**: `kube_pod_container_status_restarts_total{namespace="mo-branch-commit-a0de03067-20260624", pod=~".*tp-cn-4n4x7.*", container="main"}`

```
21:44:00Z  restarts=0   ← OOM kill 发生
21:45:00Z  restarts=1   ← 容器重启完成
```

**Metric**: `kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}` = `1` from 21:45:00Z onwards.

✅ **OOM Kill 已确认**：`tp-cn-4n4x7` 的 `main` 容器因超出 K8s 55GiB memory limit 被内核 OOM killer 终止，于 21:45 完成重启。

---

### 4. Memory Timeline Chart (Container Memory, 21:30–21:55 UTC)

```
55 GB ┤ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ K8s limit ─ ─ ─ ─
      │
48 GB ┤      *lrqjc*           *lrqjc*
      │  44.86   48.13          47.97
44 GB ┤   ●       ●              ●
      │
40 GB ┤              *4n4x7 OOM*    ●25t8q 41.61
      │                  ↓
36 GB ┤                   ●25t8q       ●dn-0 34.60
      │
32 GB ┤          ●25t8q                 ●dn-0
      │  ●dn-0
28 GB ┤
      │
 0 GB ┤                   ●4n4x7 restart (0.24 GB)
      └──────────────────────────────────────────────
       21:30  21:35  21:40  21:44  21:45  21:50  21:55
```

---

### 5. Configuration

| Parameter | Value |
|---|---|
| `cn_limits_memory` | 55 GiB (K8s hard limit) |
| `cn_gomemlimit` | 25000 MiB (Go soft limit, GOMEMLIMIT) |
| `dn_limits_memory` | 55 GiB |
| `dn_gomemlimit` | 35000 MiB |
| CN 节点数 | 3 |

---

## Key Findings

1. **堆外内存主导**：OOM 发生时 Go heap 仅 3~7 GB，但 container memory 达 44~48 GB。约 **85% 的内存是堆外分配**（CGO/mmap/mpool），GC 无法回收。这是 OOM 的直接原因。

2. **3 个 CN 均受影响**：`tp-cn-lrqjc` 也达到 48.13 GB（距 55 GB limit 仅 6.87 GB），同样存在 OOM 风险。`tp-cn-4n4x7` 只是最先触发的节点。

3. **`cn_gomemlimit=25000MiB` 无效**：Go soft limit 仅约束 Go heap，对堆外内存无约束力。实际 container memory 远超 gomemlimit，说明 vector index 构建期间的堆外分配不受 Go runtime 控制。

4. **DN 压力较轻**：DN 峰值 41.12 GB（21:52），且 Go heap 占比更高（62%），说明 DN 的内存增长主要来自 Go 堆内的 flush/compaction，相对可控。

---

## Secondary Issue: ANLI Fulltext ERROR 20105

```
ERROR 20105 (HY000): MATCH() AGAINST() function cannot be replaced by FULLTEXT INDEX
```

- 在 `nqft` 测试中出现 **90,000+ 次**
- 与 OOM 是独立问题，属于 fulltext index 功能缺陷
- 该错误导致 fulltext 测试大量失败，但不影响 IVF vector index 本身的正确性

---

## IVF DML Concurrent Tests: All Passed ✅

6 个并发场景（INSERT/UPDATE/DELETE + IVF index 维护）均正常完成：
- **0 panics**
- **0 data consistency errors**

IVF 索引的 DML 并发正确性无问题。

---

## Performance Regressions (Secondary Impact)

| Metric | Current QPM | Baseline QPM | Delta |
|---|---|---|---|
| `qvec`（向量查询） | 425 | 34,301 | -98.8% 🔴 |
| `nqft`（全文查询） | 18,306 | 47,173 | -61.2% 🔴 |
| `overall` | 425 | 3,784 | -88.7% 🔴 |

`qvec` 极端下降（425 vs 34301）是 OOM 重启后测试未完整执行的结果，非真实性能回归。`nqft` 下降与 fulltext ERROR 20105 导致的早期退出有关。

---

## Impact

- **直接影响**: IVF VECTOR INDEX TEST 整体失败（OOM 导致初始数据加载中断）
- **同类问题**: 与此前 IVF PRE POST FILTER 失败（#25114）属同一类——大规模向量数据加载阶段 CN 堆外内存暴涨
- **IVF 正确性**: DML 并发测试全部通过，IVF 索引本身无数据一致性问题

---

## Expected Behavior

LOAD DATA / INSERT SELECT 大规模向量数据集时，CN 堆外内存应受控，不超出 K8s limit。当前 `cn_gomemlimit` 仅约束 Go heap，对堆外分配无约束力，需要额外的堆外内存限制机制。

---

## Steps to Reproduce

1. 在 3-CN TKE 环境（cn_limits_memory=55GiB）运行 IVF VECTOR INDEX TEST
2. 执行 `ca_comprehensive_dataset` 的 LOAD DATA + INSERT SELECT 构建副本表
3. 观察 CN container memory 从 ~37GB 快速上升至 ~48GB（Go heap 仅 ~7GB），最终被 OOM kill

---

## Environment

- **MatrixOne**: main branch, commit `a0de03067`
- **Infrastructure**: TKE (Tencent Kubernetes Engine)
- **CN nodes**: 3 × (55GiB memory limit, 25000MiB Go soft limit)
- **DN nodes**: 1 × (55GiB memory limit, 35000MiB Go soft limit)

---

## Related Issues

- #25114 — IVF PRE POST FILTER 同类堆外内存 OOM 问题

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Bug] IVF VECTOR INDEX TEST: CN OOM killed during ca_comprehensive_dataset LOAD DATA (47.29GB peak, ERROR 2013) #25153

Summary

Root Cause

Prometheus Memory Metrics

1. Container Memory (working_set) — All Pods

`tp-cn-4n4x7` (OOM Killed)

`tp-cn-lrqjc` (未 OOM，但接近 limit)

`tp-cn-25t8q` (未 OOM)

`dn-0`

2. Go Heap (`go_memstats_alloc_bytes`) — 堆外内存分析

`tp-cn-4n4x7` Go Heap（OOM 前）

`tp-cn-lrqjc` Go Heap（对比）

`tp-cn-25t8q` Go Heap（对比）

`dn-0` Go Heap

3. OOM Kill Confirmation (kube-state-metrics)

4. Memory Timeline Chart (Container Memory, 21:30–21:55 UTC)

5. Configuration

Key Findings

Secondary Issue: ANLI Fulltext ERROR 20105

IVF DML Concurrent Tests: All Passed ✅

Performance Regressions (Secondary Impact)

Impact

Expected Behavior

Steps to Reproduce

Environment

Related Issues

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Time (UTC)	Container Memory	Note
21:44:00	(missing)	OOM kill 发生在此区间
21:44:30	0.24 GB	容器重启中
21:45:00	1.08 GB	重启完成
21:50:00	10.03 GB	重新加入集群
21:55:00	15.89 GB	内存再次上升

Time (UTC)	Container Memory	Note
21:30:00	44.86 GB
21:31:00	48.13 GB ⚠️	峰值，距 55GB limit 仅 6.87GB
21:35:00	41.56 GB	GC 回收
21:37:00	47.13 GB	再次上升
21:40:00	47.97 GB ⚠️	第二次峰值
21:45:00	38.95 GB	数据加载阶段结束
21:55:00	41.39 GB

Time (UTC)	Container Memory	Note
21:30:00	33.01 GB	基线
21:43:00	36.09 GB	开始上升
21:45:00	41.61 GB	峰值
21:47:00	35.98 GB	回落
21:55:00	36.76 GB

Time (UTC)	Container Memory	Note
21:30:00	26.71 GB	基线
21:40:00	28.96 GB	开始上升（flush/compaction）
21:43:00	33.95 GB
21:49:00	34.60 GB	峰值
21:52:00	41.12 GB	二次峰值（compaction 压力）
21:55:00	40.86 GB

Time (UTC)	Go Heap	Container Memory	Off-Heap（估算）
21:30:00	3.92 GB	(see above)	~40 GB
21:31:00	6.30 GB
21:35:00	4.92 GB
21:40:00	5.87 GB
21:42:00	6.70 GB
21:44:00	3.49 GB	(OOM kill)
21:45:00	0.47 GB	1.08 GB	容器已重启
21:50:00	0.52 GB	10.03 GB	重启后 Go heap 极低

Time (UTC)	Go Heap	Container Memory	Off-Heap 估算
21:30:00	8.46 GB	44.86 GB	~36 GB (80%)
21:31:00	4.82 GB	48.13 GB	~43 GB (90%)
21:37:00	14.51 GB	47.13 GB	~32 GB
21:40:00	12.06 GB	47.97 GB	~36 GB (75%)
21:44:00	13.17 GB	45.25 GB	~32 GB
21:55:00	7.32 GB	41.39 GB	~34 GB

Time (UTC)	Go Heap	Container Memory	Off-Heap 估算
21:30:00	3.44 GB	33.01 GB	~29 GB (88%)
21:35:00	7.29 GB	33.46 GB	~26 GB
21:44:00	12.13 GB	37.86 GB	~26 GB
21:55:00	9.70 GB	36.76 GB	~27 GB

Time (UTC)	Go Heap	Container Memory
21:30:00	5.19 GB	26.71 GB
21:40:00	17.08 GB	28.96 GB
21:43:00	16.93 GB	33.95 GB
21:49:00	18.29 GB	34.60 GB
21:52:00	25.73 GB	41.12 GB
21:55:00	10.21 GB	40.86 GB

Parameter	Value
`cn_limits_memory`	55 GiB (K8s hard limit)
`cn_gomemlimit`	25000 MiB (Go soft limit, GOMEMLIMIT)
`dn_limits_memory`	55 GiB
`dn_gomemlimit`	35000 MiB
CN 节点数	3

Metric	Current QPM	Baseline QPM	Delta
`qvec`（向量查询）	425	34,301	-98.8% 🔴
`nqft`（全文查询）	18,306	47,173	-61.2% 🔴
`overall`	425	3,784	-88.7% 🔴

Uh oh!

[Bug] IVF VECTOR INDEX TEST: CN OOM killed during ca_comprehensive_dataset LOAD DATA (47.29GB peak, ERROR 2013) #25153

Description

Summary

Root Cause

Prometheus Memory Metrics

1. Container Memory (working_set) — All Pods

tp-cn-4n4x7 (OOM Killed)

tp-cn-lrqjc (未 OOM，但接近 limit)

tp-cn-25t8q (未 OOM)

dn-0

2. Go Heap (go_memstats_alloc_bytes) — 堆外内存分析

tp-cn-4n4x7 Go Heap（OOM 前）

tp-cn-lrqjc Go Heap（对比）

tp-cn-25t8q Go Heap（对比）

dn-0 Go Heap

3. OOM Kill Confirmation (kube-state-metrics)

4. Memory Timeline Chart (Container Memory, 21:30–21:55 UTC)

5. Configuration

Key Findings

Secondary Issue: ANLI Fulltext ERROR 20105

IVF DML Concurrent Tests: All Passed ✅

Performance Regressions (Secondary Impact)

Impact

Expected Behavior

Steps to Reproduce

Environment

Related Issues

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

`tp-cn-4n4x7` (OOM Killed)

`tp-cn-lrqjc` (未 OOM，但接近 limit)

`tp-cn-25t8q` (未 OOM)

`dn-0`

2. Go Heap (`go_memstats_alloc_bytes`) — 堆外内存分析

`tp-cn-4n4x7` Go Heap（OOM 前）

`tp-cn-lrqjc` Go Heap（对比）

`tp-cn-25t8q` Go Heap（对比）

`dn-0` Go Heap