【你目前使用的版本】 7.5.4 【最需要 v8.5 的哪些新功能】 全局索引 【还有哪些产品需求】 聚簇索引支持修改为非聚簇索引主键

只要 TOS 支持 S3 协议就大概率没问题，一般来说 rclone 支持就没问题。

把 net.ipv4.tcp_retries2 设置为 5 吧，这个是遵循指数退化逻辑的，15次代表要910多s 才能会将异常的 TCP 连接释放，改成 5 代表 20多秒 就不再重试了，现在网络质量都比较好，没必要重试那么多次。 看下改过后，能不能将连接稳定到一定的数目吧。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

看下操作系统的 net.ipv4.tcp_retries2 是什么？ 感觉可能是网络质量不好，导致 TCP 连接一直没有释放。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

https://github.com/pingcap/tiflash/issues/9695 创建了一个 issue

那需要我创建一个 github issue 么？还是你们内部跟踪就好了？

这个修复应该后续会放到 7.5 后续的小版本里吧？ 刚升级版本到 7.5.4，预计最快也要明年 6 月份才可能再次升级大版本。

[image] 通过 tc 命令将 入流量限制到了 5Gb/s，看监控也真的限制住了，但是奇怪的是还依旧有报错。现在怀疑到底是不是网卡流量限制导致的获取文件失败，还是 TiFlash 内部处理问题导致了。

这个超时是指什么超时啊？应该用哪些参数控制的？

[image] 另外请求路由策略也可能有问题，找了个报错的OSS 文件看了下，发现所有 Compute 节点报错的文件都是同一个，路由策略正确的话，不应该每个 OSS 文件只会由其中其中一个节点下载么？

让 AI 分析一下这个错误信息，说是下载时候网络出现了抖动导致的，看了下监控当时流量确实也达到机型的网络上限，所以问题就变成了： 有什么办法可以增加重试，或者降低网络读取速度(这个已经确定当前还不支持)么？ 为什么多次重试也一样有报错，理论上应该会后台缓存到本地的磁盘上的吧？ 下面是 AI 的分析结果： 状态分析: state=0x06 在iostream中表示 failbit(0x02) | eofbit(0x04)的组合 这表明流既达到了EOF，同时也发生了某种失败 数据分析: 请求读取大小：size=1048592 (约1MB) 实际读取大小：gcount=589…

报错代码可以看到是这里，不过为什么返回值是errmsg=Success，但还是报错了。

今天又出现这个错误了，重试多次也都是失败了，每次失败报的文件还不一样。下面是 TiFlash Compute 节点的报错信息 [2024/12/02 16:06:34.704 +08:00] [ERROR] [S3RandomAccessFile.cpp:98] ["Cannot read from istream, size=1048592 gcount=589262 state=0x06 cur_offset=0 content_length=1504148 errmsg=Success cost=5215266ns"] [source=s18195849145/data/t_82592…

[image] 另外设置一下auto analyze 的时间段，只放到凌晨低峰期来执行，让后续处理时暂时不会再自动产生 anlyze table，

另外看报错日志里，是加载 Partition 的统计信息问题导致的，可以尝试一下先 DROP 一下正在执行 analyze table的分区表的统计信息，看能不能正常启动 https://docs.pingcap.com/zh/tidb/stable/sql-statement-drop-stats

另外可以通过下面的连接，限制一下analyze table的并发 https://docs.pingcap.com/zh/tidb/stable/statistics#控制-analyze-并发度