才开始用就集群崩溃被oom-killer

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】8.5.3
【复现路径】无
【遇到的问题：问题现象及影响】
整个集群崩了, pd,tidb,tikv,tiflash 先后挂了,且无法重启. 共9台机子,3台tidb和3pd,其中tidb和pd共用两台,其中一台装haproxy负载, 目前试运行阶段,数量和请求都不大. 最大的一个慢查询20秒,约10多万数量,查询很快,发送占用大部分时间

程序被操作系统oom kill后,系统服务自动重启失败

t1
t11091×639 84.3 KB

t2
t21778×426 41.1 KB

t3
t31510×462 91.2 KB

oom
oom1743×770 64.7 KB

2
  • 建议 ：
    • 检查系统内存配置，考虑增加物理内存或调整虚拟内存设置。
    • 分析TiKV进程的内存使用模式，优化其配置或限制其资源占用。
    • 检查硬盘sr0的硬件状态，排除硬件故障或驱动兼容性问题。
3

检查一下系统的 ulimit -n,如果 FD limit 设置过低，TiKV（通常需要高并发文件句柄）在启动时可能因无法打开 SST 文件而卡死或崩溃。

1 个赞
4

但凡有办法，别把服务都部署在一个节点，资源争抢，优化很闹心的

1 个赞
5
  • 停止 PD/TiDB 共用节点：PD 单独部署在 3 台节点（至少 2 核 4G / 节点），TiDB 单独部署（至少 4 核 8G / 节点），HAproxy 单独部署在负载节点（1 核 2G 足够）；
  • 内存硬限制：所有组件内存配置≤节点物理内存的 60%（留足系统 / 缓存空间）。
1 个赞
6

尽量还是单部，避免混部（混部的机器配置得高一些）

3 个赞
8

从sql入手看看能不能优化，你这个不是混合部署的问题

9

先登录每台节点，收集 OOM 相关日志和组件日志，定位具体内存耗尽的组件， 临时释放节点内存， 再逐个重启组件

10

先通过系统日志定位 OOM 进程，清理环境后分步重启集群，再通过调整配置、优化查询、规划节点资源避免复发

11

看着是节点资源共用导致内存竞争 + 内存配置不合理导致的问题

12

测试阶段,平时内存占用只有一点. 已经是64G内存了

13

64G内存的机子