这里如果不是worker，而是thread级别就没问题
有没有尝试过参数 = 8 的现象，
现在资源利用率极低，一台服务器（云服务器）部署两个tiflash节点可以吗？
还没试，配置了16运行了几个小时。我调整一下试试
单机部署多个节点可以解决单worker瓶颈，如果后面遇到大并行计算，节点cpu也会瞬间爆炸
tiflash副本数量是不应该和tiflash节点数量保持一致？
你这个场景把threads调整到8，单机部署4个节点，应该也是可行的
单机没必要，多副本也是为了利用多节点的计算资源，重点在计算资源
即使一个服务器部署2个tiflash节点还是会出现这样的问题。像是下面的BUG并没解决
只能等发版解决吗？有没有临时解决方案？
tiflash_wait: {pipeline_queue_wait 高是 rc 的限制。
-
方案 1 关闭 tiflash 的 rc 功能绕过 rc 的限制。
#添加关闭tiflash RU配置
tiup cluster edit-config
tiflash:
profiles.default.enable_resource_control: false -
查看 olap 的 rc 是不是有瓶颈。
可以进一步上传 clinic 看看。
应该是这个rc资源管控的原因了，我也发现每次阻塞的时候 tiflash resource group波动都很大
1 个赞
问题根源是 TiFlash 任务调度排队pipeline_queue_wait 高，而非计算资源不足，建议优化查询计划、减少小任务数量。
1 个赞
附了SQL和执行计划，简单的单表统计。正常情况下走tiflash查询也就几十毫秒
TiFlash Resource Group 和正常的 Resource Group 不知道是什么关联关系。资源组5w的配额，高峰期2k，但是 TiFlash Resource Group 波动非常大。
几个 tiflash节点？
不要用 tiflash 的面板看，用截图中编辑 ru 面板的表达式把 tp 改成 ap 来看，或者新增一个 ap 来看，是不是当时 ru 耗尽了。
已经升级了
按照你这个面板查看，ru配额5w，tp消耗2k左右，ap消耗不到90。tiflash就阻塞的不行了。这是怎样的配比关系，太不正常了