tispark用的就是spark的catalyst引擎来生成执行计划的。 这块的执行计划的选择大概率不是tispark造成的，应该和catalyst实现有些关系。 你可以阅读一下这个文章。尝试调大spark.sql.autoBroadcastJoinThreshold的值，看看是否能让join的方式发生变化。

[image] 问题可能就在你3个组件混合部署上。 tikv使用cpu比较野蛮，如果并发高了，可能导致pd抢不到时间片运行。就会超时。 建议pd和tidb放一起，tikv单独放一台机器。

这个错误一般来说不严重，如果是region正好在分裂或者合并都会有这个报错。仅从这个报错不能充分的证明gc被卡住了。 建议查一下grafana 上的 tikv-details->GC->TiKV auto GC safepoint， 观察 gc safepoint 推进是否符合预期。这个才是决定性的gc卡住的证明。

select table_schema,table_name from information_schema.tables where tidb_table_id=4611686018427387978 类似这样找。

复现了以后，日志里面也是没有任何异常嘛？ 如果说日志上都看不出问题，就很难定位了。

[image] 这个图

[image] https://docs.pingcap.com/zh/tidb/stable/daily-check/#pd-tso-wait-duration 这个值不正常，高的离谱。正常tidb/tikv到pd如果是1ms以下的ping值，这个值最高也就是20ms。你这个盲猜个别节点可能ping值都有2-3ms了。 查一下是不是集群中有些节点跨子网了。

看你以前的帖子，用的是nfs备份？备份限速了嘛？带宽占满了可能导致nfs访问不了。最好还是用s3.

这两者最大的区别在于 : 标准大页管理是预分配的方式，而透明大页管理则是动态分配的方式。 THP是给HP添加了一个中间层。看完上面这个说明，我感觉tidb整体就不是oracle那种预分配管理内存的模式。 所以应该是不需要启用操作系统大页的。当然THP本来文档中就是建议关闭的。

这是复制完了，都没看一眼啊。 这不是无人区，兄弟。

理论上可以，强制缩容这台，再重新布。 不过你一台tikv啥配置，我感觉腾讯云再申请一台在，撑死也就是一个月多几千的成本，至于玩这么极限的操作么。 这几千和数据库的安全比起来，我是老板，我宁可多花点钱。也不要弄得集群整个出问题了。那损失更大。 你还是要确认一下另外两台tikv的存储够用么，我感觉另外2台现在存储也很危险了，不扩容弄个再坏一台tikv，就真的难救了。

要上报的，再坏一台tikv就集群不可用了。问题不小了。

没啥影响，反正都是起不来，最坏也不过是不好定位原因。

还是小了，80%以上的磁盘占用就会告警。不过现在看磁盘还不是根因。这个版本也低了，不行就找一台新机器扩容，缩容一下看看。 其实我还担心你这个集群本来就是最小3tikv部署的，现在挂了一台tikv，极限情况也就挂2个tikv，我担心另外2个tikv的存储也快满了，最好是先扩容一台tikv。再回头来搞这个出问题的tikv。

我看你另一个帖子了，你在里面写存储不够了。 这个就是原因，直接从腾讯云控制台进去给这个机器扩存储，扩完了之后，直接重启这个机器。应该就会恢复正常。 问题就是没存储了。raft日志应用不了，tikv报错退出了。

原来是磁盘不够了是么，你另一帖子写的是腾讯云对吧？ 你直接通过腾讯云给这个机器扩存储，扩完了以后直接重启这个机器就好了，不需要通过缩容/扩容折腾一遍了。

[image] 这个进程id都有，你要说完全没起来过，我很难相信啊。

最好是有资源分开，3个组件挤一起很难稳定，最好是pd和tidb一起占一台，tikv独占一台。 哪怕单台4c8g也能保持稳定的。