当前TiFlash 不支持对 S3 读取的 QPS/带宽做限制，在生产环境中出现了类似 TiFlash存算分离架构查询偶尔会报“no alive tiflash, cannot dispatch BatchCopTask”的错误 的告警，这是因为突发 S3 流量下载量太大，突破了机器的网卡带宽限制，导致 Compute 节点对 Write 节点的探活失败引起的。
目前只能通过降低 TiFlash 查询并发缓解问题，不能根治，希望能增加一下读取 S3 的一些限流措施，毕竟 S3 这类云服务往往都会有 QPS 或者 带宽限制，如果瞬时流量太大，运营商会直接限流，也会导致查询失败。
下面的三个问题，其实根因都是 S3 突发下载流量太大导致的：
大佬，请问贵公司tiflash用了存算分离到S3
有两个问题：
1、对于本地ssd盘有多少性能损耗？
2、成本降低多少（上传、下载s3费用高吗）？
这里应该指的是“对比本地 SSD盘在查询效率上有什么区别？”吧，实测下来对业务的查询，如果是首次查询走到 S3 上会有3、4倍的增长，跟需要下载的数据量有关系。 如果数据已经缓存到 Compute 节点的本地磁盘了，则和原来的查询效率一样。
不过之前因为成本问题，只将部分数据设置了 TiFlash 副本，用了存算分离架构后，就可以低成本地将所有表都设置 TiFlash 副本。 对分析类 AP 查询而言，即便是TiFlash 直接从 S3 读取数据，也会比本地盘的 TiKV 效率能提升 5-10 倍。
带宽成本： 因为我们机器都在云上，走的是内网流量，带宽是不收费的。不过如果是走的是公网带宽，这个成本就相当大了，不建议用公有云的对象存储服务，自己用 Minio 搭建S3集群成本会更低，性能其实也可能会更好。
存储成本： OSS包年包月价格是10T 1106元，如果有商务折扣会更低。
请求成本： 阿里云 OSS是0.01 元/万次，基本可以忽略这部分成本。这个月一直在调试上传数据，虽然总存储量是25T，但是预计真实上传流量要超过50T，总的请求次数(PUT+GET)也才 8700W，也就是 87元，
感谢回复，多谢大佬。
大佬日常使用的话有什么痛点呢？比如「 S3 读取的 QPS/带宽做限制」
ps：如果大佬整理个最佳时间专栏，那就更好了 
