TiDB OOM问题 学习笔记

TiDB使用过程中，OOM最常发生在tidb组件和tikv组件。

（这里我用大写TiDB代表TiDB 数据库 ，小写的tidb代表tidb组件。下同）

今天分别来看这两个组件发生OOM的整个排查思路。

01

tidb组件OOM问题

1、如何诊断OOM？

1.1 客户端一般通过tidb来连接TiDB集群，一般OOM之后可能会出现Lost Connection to MySQL Server during query

1.2 通过日志分析

1. dmesg -T | grep tidb-server 查看系统日志，在日志中可以发现OOM-Killer日志；
2. tidb.log中，故障时间点存在Welcome to TiDB字样的日志，代表TiDB重启过；
3. tidb_stderr.log通过grep可以看到runtime：out of memory或者cannot allocate memory字样

1.3 查看grafana监控

TiDB--Server---Memory Usage面板明显增高；

TiDB--Server---Uptime确认最新的tidb运行时间；

2、tidb组件OOM原因？

2.1 SQL语句的执行

2.2 Golang内存释放机制

3、OOM解决办法

3.1 处理慢SQL

慢SQL定位方法

1. 定位内存大的SQL，并进行优化
2. TiDB Dashboard SQL分析
3. TiDB Server日志中的expensive Query

慢SQL优化方法

1. SQL优化，减少非必要返回的数据量（创建索引，强制使用索引等）
2. 减少大事务，将大事务拆分成小事务
3. 调整tidb server的相关参数，从而限制单条SQL 内存的使用（包含 限制单条内存 mem-quota-query参数、oom-action参数；临时磁盘参数oom-use-tmp-storage、tmp-storage-path、tmp-storage-quota等）

3.2 调整Go 内存释放策略

Go语言有两种内核的内存释放策略，分别是MADV_DONTNEED和MADV_FREE,后者是前者的改版，后者释放的内存更多，但是释放的慢（惰性释放），前者释放的内存较少，但是释放的很快（积极释放）

3.3 滚动重启TiDB Server回收内存。

02

tikv组件OOM问题

1、tikv OOM对业务的影响？

1.1 tikv上请求失败造成异常退出

1.2 region leader 重新选举，影响性能

1.3 region cache重新更新，PD将最新的region leader信息更新给tidb server的region cache

2、tikv OOM诊断方法？

2.1 日志

dmesg -T | grep tikv-server 系统日志中的OOM-killer日志

tikv.log 宕机前后时间的Welcome to TIKV日志，也就意味着tikv重启了

2.2 grafana监控

tikv--Detail--Cluster--Memory查看内存使用情况（一般是先到峰值，然后迅速到0，意味着重启）

3.tikv OOM的原因？

3.1 block-cache配置不当导致OOM

3.2 Coprocessor接受大量大查询，返回的数据量很大，gRPC的发送速度跟不上Coprocessor往外输出的速度，导致数据堆积在tikv里面，内存溢出（具体是查看tikv--Detail--Coprocessor Overview --Total Response Size 监控图，是否已经大于Node_exporter--Network--Network In/Out Traffic监控图的值，如果大于，说明是这个原因）

3.3 其他进程占用太多内存

4、OOM优化方法？

4.1 storage.block-cache.capacity,这个值大概配置成总内存的45%~60%左右，tidb-4.0.13版本之后可以支持动态调整

4.2 SQL优化，根据业务逻辑和执行计划来优化SQL，尽量少查询数据，避免gRPC的发送速度跟不上Coprocessor往外输出的速度

4.3 网卡配置升级（千兆升级万兆等等）

4.4 避免其他组件和当前组件混部