升级6.1后，TiFlash服务异常

🪐 TiDB 技术问题 TiFlash
, ,
15

@qihuajun 想了解下这些信息

  1. 具体是从什么版本升级到 6.1.0 的，以及升级 6.1.0 具体发生在什么时间点？
  2. 混布 tikv 和 tiflash 的 6 台机器 192.168.14.23~28，机器配置是怎么样的？
  3. “把分区动态裁剪关掉，积压的查询kill掉之后TiFlash的查询恢复正常” 根据这个描述，判断可能是使用了 6.1.0 的分区动态裁剪，但是没有手动更新统计信息，导致到 tiflash 上的执行计划有变更，进而引起了 OOM 的情况。

请问是在升级 6.1.0 之后，才开启分区动态裁剪的么？开启之后，有没有手动更新过统计信息呢？
https://docs.pingcap.com/zh/tidb/stable/partitioned-table#动态裁剪模式

另外我从监控看到 tikv 常驻使用内存在 110GB，tiflash 进程内存大概达到 30 GB 左右就会发生重启。如果机器配置是 150G 左右内存，在 tikv 和 tiflash 混布的情况下，110GB 都分配给了 tikv，留给 tiflash 的可用内存太少了，这样在机器资源划分上其实不太合理。AP 查询在处理复杂查询时，会和混布的 tikv 争抢 CPU、内存、IO等资源，造成 TP 业务受影响。一般建议将 tikv 和 tiflash 分开在不同的实例部署。