exchSenderExec中是否考虑消费速度过慢导致的背压问题？

🪐 TiDB 技术问题 TiFlash
,
1

如题，目前生产者消费者建立连接后，生产端会开一个协程进到 EstablishMPPConnectionWithStoreID，里面发送数据的逻辑如下

var sendError error
for sendError == nil {
    // 从 data ch 中取数据
	chunk, err := tunnel.RecvChunk()
        ...
	if chunk == nil {
     // 所有数据都取完了
		break
	}
	res := tipb.SelectResponse{
		Chunks: []tipb.Chunk{*chunk},
	}
	raw, err := res.Marshal()
	...
	sendError = server.Send(&mpp.MPPDataPacket{Data: raw})
}

这里是持续从 data ch 读数据，然后发到接收端。如果生产速度很快，消费速度很慢，会导致数据积压在消费端，数据量大时可能会oom？

请问这里是如果考虑的，tiflash中是否有其他机制控制发送速率？

2

https://docs.pingcap.com/zh/tidb/stable/create-tiflash-replicas#加快-tiflash-副本同步速度

文档中加快同步速度的设置。我觉得你可以反向改小，试下能否解决。

-- 这两个参数默认值都为 100MiB，即用于副本同步的快照最大占用的磁盘带宽不超过 100MiB/s。
SET CONFIG tikv `server.snap-io-max-bytes-per-sec` = '300MiB';
SET CONFIG tiflash `raftstore-proxy.server.snap-max-write-bytes-per-sec` = '300MiB';

特别是上面这两个参数。

3

感谢您，但副本同步和我的问题不是一个场景，exchSenderExec是在exchange算子向下游算子发送用到的～

1 个赞
4

好吧 :joy:
我还以为和另一个问题一样是导入数据的时候tiflash就挂了。

5

设置 max-server-memory 参数来限制 TiFlash 实例的内存使用量

6

请问这里只能靠运维手段来解决吗？这算是内核的缺陷吗？

7

首先，这个“处理慢”必然会导致这个 oom 的问题吧？
其次，这个规避方案，最佳当然是提速；但是，没法提速，那可能只能这个运维手段了