# [FAQ] 如何排查 ng-monitoring 在 v5.x 发生 oom 问题

## Key Words

Prometheus, Dashboard, ng-monitoring, ngm, oom, top, cgroup.

## Description

TiDB 集群节点数量超过 30 节点，自建 Prometheus 开启 ng-monitoring-s 使用 dashboard 完整功能，但是打开 TopSQL 和 Continue profiling 时，ng-monitoring-s 发生 OOM。通过日志可以看到关键信息 “ng-monitoring-s invoked oom-killer“

## Content

原因一：

ng-monitoring-s 服务依赖的 golang 的 badger 数据库会吃掉很多内存的已知 bug，修复 PR 是 [ng-monitoring#168](https://github.com/pingcap/ng-monitoring/pull/168)，v6.5.0 以后版本已经修复；注意的是，ngm 5.3 开始支持，5.3 到 6.5 中间版本都有这个问题。

ng-monitoring-s 内存占用上涨时，可以通过 heap dump 抓取内存使用情况分析，可以定位到 Badger 的内存占用非常高，已知达到 7GiB 情况。

```golang
go tool pprof <ADDR:PORT>/debug/pprof/heap
```

原因二：

Linux 为加速进程运行而产生大量的 buff/cache 占用会统计在服务上，可以通过 `top` 命令查询 RES 和 SHR 差值计算实际服务占用内存情况。如果为了控制 ng-monitoring-s 服务内存占用，可以通过 Cgroup 或者 Docker 容器方案限制服务的占用内存上限，进而减少内存占用负载压力，ng-monitoring-s 通常使用 2 vcore 4 GiB 的资源即可，诸如 50 节点以内的 TiDB 集群规模可以考虑使用 4 vcore 8 GiB 的资源配置。

参考材料：
[Redhat 对内存使用和内存页使用指导建议](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/tuning_and_optimizing_red_hat_enterprise_linux_for_oracle_9i_and_10g_databases/chap-oracle_9i_and_10g_tuning_guide-memory_usage_and_page_cache)

RES: Resident Memory Size (KiB)：进程所占用的所有实体内存（physical memory），不包括被换出到交换区的部分。

SHR: Shared Memory Size (KiB)：进程可读的全部共享内存，并非所有部分都包含在 RES 中。它反映了可能被其他进程共享的内存部分。

CGroup: 是Linux 内核的一个特性，用于限制、记录和隔离一组进程的资源使用（CPU、内存、磁盘I/O、网络等）。

## Affected Versions

< 6.5.0