write stall 如果触发了，一般是 磁盘的性能不够…
就是生产者产生的东西太多了，消费者消费不及时… 不平衡的状态
没升级之前是ok的？
2 个赞
可以将自动收集统计信息做一下调整，调高出发阀值 https://docs.pingcap.com/zh/tidb/v5.2/statistics/#自动更新
另外确认一下下面这个参数是否是开启，如果开启调整为关闭状态。
在 v5.0 版本之前，执行查询语句时，TiDB 会以 feedback-probability 的概率收集反馈信息，并将其用于更新直方图和 Count-Min Sketch。 对于 v5.0 版本，该功能默认关闭，暂不建议开启此功能。
1 个赞
| 系统变量名 | 默认值 | 功能 |
|---|---|---|
| tidb_auto_analyze_ratio | 0.5 | 自动更新阈值 |
| tidb_auto_analyze_start_time | 00:00 +0000 | 一天中能够进行自动更新的开始时间 |
| tidb_auto_analyze_end_time | 23:59 +0000 | 一天中能够进行自动更新的结束时间 |
自动更新阈值 默认是 0.5 ，相当对 modify rows/total rows > 0.5 就会触发自动统计信息收集，如果确认阀值调整过并且比较低，可以尝试先调高。
2 个赞
我先调整到0.8 performance.feedback-probability 确认没有开启
近3个小时
tidb-pro-TiKV-Details_2021-12-29T23_46_26.435Z.rar (1.8 MB)
0~3点，
tidb-pro-TiKV-Details_2021-12-30-0.0.0~3.0.0.rar (1.8 MB)
对， 升级之前没有发现这种oom的情况， 28写入有点异常，后面排查是一台物理机cpu被降频导致。
有点奇怪，升级大版本的小版本，参数应该都是继承不变的，并且5.0.3没问题，5.0.5就有问题。感觉analyze 只是结果现象，真正的原因没有发掘。
早上把bi的数据分析开起来后， 一大票的oom 又要崩了
Hi ～ 发现一个潜在的问题，先试试调整一下，关闭 gc compaction filter
https://docs.pingcap.com/zh/tidb/v5.2/garbage-collection-configuration/#gc-in-compaction-filter-机制
2 个赞
gc.enable-compaction-filter 这个参数改成false了，
下面这个是近两个小时的clinic数据
https://clinic.pingcap.com:4433/diag/files?uuid=e0c8d5299a8ed056-fd163bfc8aa67803-e3478be9a3b3f9cd
坐等5.0.6版本发布或回退到5.0.4，之前和官方小伙伴确认过5.0.5版本gc处理有异常会引发OOM
回退可使用tiup cluster patch方式
2 个赞
还有这回事, 我的版本是从4升级上来的 ,我看了下 mysql.tidb里面gc的配置还在, gc.enable-compaction-filter 这个参数应该是5.0以后开始的,
gc.enable-compaction-filter关掉以后, 时间到了 还是会gc, 但是内存目前没出现oom了…
2 个赞
OK，这个问题现在确认是 gc 的实现导致的了。此处做个复盘：
昨天排除 gc 问题导致 oom 的原因是这样的：
- 因为从监控看 gc 的 任务量 和 Duration 以及其他指标在 OOM 时并未出现明显异常飙涨能直接导致 OOM 的情况，甚至几乎都是下降的，因此确定可以先排除掉 GC 导致的 OOM，而判断是 analyze 是因为这段时间内唯一的比较大的负载就是 Ananlyze（耗时以及数据量都很大），其他请求基本可以忽略。没法确定 gc 和 analyze 谁引起的 OOM 是因为都没有直接的内存使用数据。
- 监控中，work pending task 这个指标的公式设置不正确，应该设置为计算总 pending task 量(sum(tikv_worker_pending_task_total{tidb_cluster=“$tidb_cluster”, instance=~“$instance”}) by (name))，而该版本的公式为 rate/1min。指标当前版本显示的情况 和 正确的显示情况如下图所示，错误情况下该指标在 OOM 时刻只有几百，并且还是下降的。但根据正确的监控指标，OOM 时堆积了百万级别的任务量，且是持续堆积飙涨的，就可以直接判断出是跟发生 task 堆积有关了。
- GC 导致的 OOM 问题恰好之前有同学专门定位解决过，可以升级到高版本（5.0.6，5.1.3,5.2.3 +）。
4 个赞
坐等新版本更新…
升级5.0.6后没有出现oom了。
1 个赞
兄弟问下，升级5.0.6后，gc.enable-compaction-filter是保持false，还是改回默认的true了？
##我这边5.2.2升级5.2.3后，gc的delete range总是失败，同样的参数设置成false后才成功。
改回true了。
1 个赞
收到~多谢
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。