【 使用环境 】生产环境
【 OB or 其他组件 】ob
【 使用版本 】4.2.1-10BP
【问题描述】
下图为部署ob集群的机器内存使用监控图。 有台机器(黄色线条)在9点-10点之间存在内存暴增 10%+。 持续时间还不短。如果继续上涨，就存在内存溢出导致宕机的风险。
查看集群监控，黄线对应的机器内存使用率未有变化
下图为集群配置。红色框起来的机器为内存暴增的机器。物理机内存规格分别为256G和512G。分配给租户使用的内存都为总物理内存的75%左右
而且图一中，在下午1点到2点期间还有其他2台机器存在突然爆内存的情况。
上述所有机器都仅运行了oceanbase、obagent服务
把暴涨的这个时间段的observer.log日志发一下 几个节点的日志都发一下
这里显示你的内存实际是已经分配完了的。500租户分配了多少内存？
这台机器实际上是有512G内存的。 只是参数设置了集群可分配内存为410G
obdiag gather scene run --scene=observer.memory --from “2022-06-30 16:25:00” --to “2022-06-30 18:30:00”
https://www.oceanbase.com/docs/common-obdiag-cn-1000000002200435
麻烦参考楼上淇铭老师的使用obdiag收集一下
问下这个图是监控主机内存的使用率的么？
当前节点有没有obproxy呢？ ocp-agent的内存给的多少？
确认下是不是2025年03-06 9:00 - 10:10 这个时间段ob机器上的日志还在不在。
说明：obdiag gather scene run --scene=observer.memory 本身没有加内存高低的判定策略在，你执行的时候他会获取对应时间的日志、内存信息和主机等信息，所以没收到日志得看下是不是日志已经过期清理了
看一下日志设置的级别 看着设置的不是wdiag级别呀
SHOW PARAMETERS LIKE ‘%syslog_level%’;
这边不允许访问你给的链接，文件麻烦压缩一下发出来。
observer3.log.zip (19.9 MB)
observer_wf.zip (6.2 KB)
observer1.log.zip (18.8 MB)
observer2.log.zip (19.3 MB)
这个图监控的ob数据库的内存使用率还是主机的内存使用率？
[2025-03-06 09:28:43.663903] WDIAG [STORAGE] ~ObOccamTimeGuard (ob_occam_time_guard.h:269) [29062][T1004_MINOR_EXE][T1004][YB42AC1EE0B2-00062B7E71BAE341-0-0] [lt=11][errcode=0] cost too much time:(null):(null), (*this=|threshold=60.00s|start at 09:27:43.602|5=59.86s|6=196.58ms|7=101us|9=3.56ms|12=2us|total=60.06s)
你好查看日志发现，你当时的数据库应该执行很慢。可以看一下ocp的sql诊断看看是不是业务积压导致的内存突增
你好 近期还有该问题，建议日志等级设置低一点，之前的日志看不到相关内存信息
观摩学习
