升级7.1.0 版本查询变慢，copr_cache_hit_ratio降低2个数量级

Bug 反馈
集群升级7.10后，原来简单的sql 执行变慢，基本出现翻倍或者更多的情况，对比之下计划，发现total_process_keys 增加2个数量级
【 TiDB 版本】7.1.0
【 Bug 的影响】业务的整体任务调度都受到影响

【可能的问题复现步骤】

【看到的非预期行为】7版本执行计划

| StreamAgg_20               | 1.00         | 1         | root      |                                                                             | time:10.1s, loops:2, RU:525106.464870                                                                                                                                                                                                                                                                                                                                                                   | funcs:count(Column#10)->Column#5 | 4.19 KB   | N/A  |
| └─IndexReader_21           | 1.00         | 405       | root      |                                                                             | time:10.1s, loops:2, cop_task: {num: 405, max: 1.03s, min: 301.6µs, avg: 364.4ms, p95: 617.5ms, max_proc_keys: 1177355, p95_proc_keys: 1139515, tot_proc: 2m17.8s, tot_wait: 168.5ms, rpc_num: 405, rpc_time: 2m27.6s, copr_cache_hit_ratio: 0.09, build_task_duration: 1.05ms, max_distsql_concurrency: 15}                                                                                            | index:StreamAgg_8                | 721 Bytes | N/A  |
|   └─StreamAgg_8            | 1.00         | 405       | cop[tikv] |                                                                             | tikv_task:{proc max:1.03s, min:170ms, avg: 397.6ms, p80:506ms, p95:617ms, iters:313964, tasks:405}, scan_detail: {total_process_keys: 293431895, total_process_keys_size: 31397210713, total_keys: 293432280, get_snapshot_time: 125.4ms, rocksdb: {delete_skipped_count: 228, key_skipped_count: 296859919, block: {cache_hit_count: 918691, read_count: 5, read_byte: 104.4 KB, read_time: 73.8µs}}}  | funcs:count(1)->Column#10        | N/A       | N/A  |
|     └─IndexFullScan_19     | 321297271.00 | 321297993 | cop[tikv] | table:dws_datav_new_register_user_real, index:uniq_card(CH_ID_CARD_ENCRYPT) | tikv_task:{proc max:1.03s, min:170ms, avg: 396.6ms, p80:503ms, p95:616ms, iters:313964, tasks:405}     

【期望看到的行为】5版本执行计划

id                    	task     	estRows  	operator info                                                                                	actRows  	execution info                                                                                                                                                                                                                                                                          	memory 	disk
	StreamAgg_20          	root     	1        	funcs:count(Column#10)->Column#5                                                             	1        	time:584.6ms, loops:2                                                                                                                                                                                                                                                                   	4.18 KB	N/A
	└─IndexReader_21      	root     	1        	index:StreamAgg_8                                                                            	405      	time:584.6ms, loops:2, cop_task: {num: 405, max: 559.3ms, min: 221.3µs, avg: 5.65ms, p95: 10.8ms, max_proc_keys: 1128106, p95_proc_keys: 0, tot_proc: 1.51s, tot_wait: 488ms, rpc_num: 405, rpc_time: 2.28s, copr_cache_hit_ratio: 0.99}                                               	1.17 KB	N/A
	  └─StreamAgg_8       	cop[tikv]	1        	funcs:count(1)->Column#10                                                                    	405      	tikv_task:{proc max:1.02s, min:170ms, p80:492ms, p95:673ms, iters:311496, tasks:405}, scan_detail: {total_process_keys: 2852371, total_keys: 2852374, rocksdb: {delete_skipped_count: 9, key_skipped_count: 2852380, block: {cache_hit_count: 4501, read_count: 0, read_byte: 0 Bytes}}}	N/A    	N/A
	    └─IndexFullScan_19	cop[tikv]	318769361	table:dws_datav_new_register_user_real, index:uniq_card(CH_ID_CARD_ENCRYPT), keep order:false	318769817	tikv_task:{proc max:1.02s, min:169ms, p80:490ms, p95:672ms, iters:311496, tasks:405}, scan_detail: {total_process_keys: 0, total_keys: 0, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 0, read_count: 0, read_byte: 0 Bytes}}}                     	N/A    	N/A

7
copr_cache_hit_ratio: 0.09

5
copr_cache_hit_ratio: 0.99

缓存命中率也差一个数量级。

https://docs.pingcap.com/zh/tidb/stable/coprocessor-cache#下推计算结果缓存

看看是不是缓存配置有变化？

key_skipped_count: 296859919 数据更新次数太多

参考 https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries

采用的原地升级方式，升级到7.1会变更这个配置？
大佬，有什么办法能检查内存大小么 capacity-mb
发现升级后，缓存miss非常多
Coprocessor Cache 少量数据缓存失效？大量数据copr_cache_hit_ratio信息出现在cop[tikv] - #4，来自 这道题我不会 文档中提到，但是缓存使用场景。但是实际没改过 capacity-mb

image3444×1670 485 KB

升级前后业务场景没有变化，不知道是不是更新太多这个问题。

发现遇到bug，但是没说是如何修复，只能等升级？

https://github.com/tikv/tikv/pull/15078

只对dws_datav_new_register_user_real这个表做compact ,加-c write -d kv

mysql -uroot -pXXX -hxxx -PXXX information_schema -e “select region_id from tikv_region_status where db_name=‘oltp’ and table_name=‘sbtest8’”>region_list
cat region_list|while read line
do
tiup ctl:v7.1.0 tikv --host xxxx:20160 compact -r $line -d kv -c write --threads 1 --bottommost force
tiup ctl:v7.1.0 tikv --host xxx:20160 compact -r $line -d kv -c default --threads 1 --bottommost force
done

大佬，这样做的原理是什么？

同时，host xxx:20160 这个选哪个tikv ？

可以参考 https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries

没太懂要怎么处理。。。

就是手工compact下这个表对应的region，你表里没啥数据，但是region里面有很多tombstore数据，需要compact下，SELECT * FROM INFORMATION_SCHEMA.TIKV_REGION_PEERS;—这个表可以确定那些region对应在哪些tikv上。

好的，我试试

image1066×498 20 KB

变慢是升级到7后立马就变慢了还是过了一段时间后？ 这里执行计划贴的是同一个SQL吗？

和这个bug应该没关系，这个一般都是不会打开的。年底才GA的功能。
7
key_skipped_count: 296859919
5
key_skipped_count: 2852380

* Rocksdb_key_skipped_count：RocksDB 扫数据时遇到的已删除 (tombstone) Key 数量。

还是从tombstone key的数量入手吧。

gc时间，safepoint是否推进，或者手工compact。

立马慢了

在推进.

现在有很多的empty的region，一直在清理。

image835×255 25.6 KB

同一个sql，简单的查 count()

比较奇怪 为啥升级后total_process_keys也变高了。

• total_keys：Coprocessor 扫过的 key 的数量。
• processed_keys：Coprocessor 处理的 key 的数量。与 total_keys 相比，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。

image1089×444 20.5 KB

2个执行计划一样，索引扫描的act rows也很接近，理论上 7版本的total_processed_keys 应该才是最接近实际的

如果有测试环境，建议只跑这一条语句，多次跑后看看执行计划信息。感觉像是其它语句行为有变化挤占了region结果集缓存，这个语句缓存命中率太低了。如果在测试环境只跑这一条语句还是不符合预期，那么可能是产品问题。如果多次跑后比较快，就要排查哪些其它语句走了缓存，这个从两方面看：一个是有一些简单sql的执行计划是否变化了，挤占了缓存，另一个是看7.1较之前版本对缓存的场景是否增加了，如果增加了，也可能挤占缓存空间。

你的集群是整体SQL都变慢了吗？