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 通过日志分析
dmesg -T | grep tidb-server 查看系统日志，在日志中可以发现OOM-Killer日志；tidb.log中，故障时间点存在Welcome to TiDB字样的日志，代表TiDB重启过；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定位方法
定位内存大的SQL，并进行优化 TiDB Dashboard SQL分析 TiDB Server日志中的expensive Query慢SQL优化方法
SQL优化，减少非必要返回的数据量（创建索引，强制使用索引等）减少大事务，将大事务拆分成小事务调整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 避免其他组件和当前组件混部
