【 使用环境 】测试环境
【 OB or 其他组件 】longhorn v1.6.0 OceanBase v4.3.5
【 使用版本 】ob-operator V2.3.4、OceanBase Dashboard V0.5.0
【问题描述】
通过ob-operator V2.3.4、OceanBase Dashboard V0.5.0 部署ob集群， 集群运行一段时间后。某台实例cpu用满分配的20核，查看pod会提示too many open files， 然后kubectl 命令都无法正常执行，随后集群节点的ssh无法正常登录。
其他问题： ① 配置集群拓扑Topology下toleration里的值的value为空是无法配置
②集群的三个节点都打上了taint， dashboard 的定期清理任务自动创建，在哪儿配置其toleration
③dashboard 的定期清理任务会提示pvc冲突，无法正常运行
【复现路径】问题出现前后相关操作
【附件及日志】
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
6 个赞
论坛小助手
#3
您好，您提的这个技术问题可能牵涉到 OceanBase 企业版范围内的功能细节；针对此类问题，建议你通过以下方式寻求帮助：
-
如你所在的企业客户已签署 OceanBase 企业版销售合同，请你联系客户经理；
-
如你所在的企业客户尚未签署 OceanBase 企业版销售合同，你可通过OceanBase官网商务咨询页面留下你的联系方式，OceanBase企业版的业务顾问会在一个工作日内与你联系。
另外，我们欢迎你使用社区版，并在论坛/社群中分享你对社区版本的想法、经验和问题，与其他社区成员共同交流。
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
1 个赞
甘霖
#4
提示too many open files是因为节点或容器本身的文件描述符限制不够。OceanBase 对 fd 数量要求比较高，建议检查下 Pod 内的 ulimit -n 以及节点的
fs.file-max 是否足够（建议 655350+）。另外 longhorn 本身也会占用不少 fd，叠加起来容易超限，超限后会引发级联故障导致节点不可用。
其他问题：
问题1: Dashboard 后端对 value 字段加了 required 校验，导致 operator: Exists 时无法留空。临时绕过： 直接通过 kubectl edit obcluster 配置 toleration，不走 Dashboard。
spec:
topology:
- zone: zone1
replica: 1
tolerations:
- key: "your-key"
operator: "Exists"
effect: "NoSchedule"
问题2: 目前 Dashboard 创建巡检任务时没有在 PodSpec 里设置 tolerations，API 也不支持传入
问题3: 巡检 CronJob 用的是 ReadWriteOnce 的 PVC，如果前一个 Job 没跑完/没释放，新 Job 挂载同一个 PVC 就会冲突。longhorn RWO 卷跨节点调度时也容易出 Multi-Attach 错误。
1 个赞
Pod 内的 ulimit -n 以及节点的fs.file-max是否需要在chart的yaml修改，还是只用修改物理机的参数限制即可。 看到这个错误时在pod内看ulimit -n 是65535， fs.file-max 也设置了65535，后来集群还是挂了。问题1直接通过 kubectl edit obcluster 配置 toleration，然后该pod 就提示pvc被占用，无法执行，后面定时任务又不停的创建pod. 问题2: 如果把Dashboard巡检任务删掉是否有影响
1 个赞
