社区版OCP4.3.0所在主机出现网络流量大的现象导致OCP应用出现不能使用

OceanBase 技术问题
,
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】社区版OCP4.3.0
【 使用版本 】社区版OCP4.3.0，metadb(OB4.1.0)
【问题描述】OCP所在主机突然出现网络流量非常大的现象，让网工限制OCP主机流量后重启OCP可以正常使用，但是网络流量依然很大，重启OCP上主机的agent后流量出现下降的现象。但是网工取消OCP主机流量限制后，OCP继续出现不可用的现象，日志报no memory or reach memory limit错误，提高metadb内存之后重启OCP也无法解决，只有取消OCP主机流量后，重启OCP才可以解决。这是不是产品的问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根据您描述的情况，社区版OCP4.3.0所在主机出现网络流量大的现象导致OCP应用出现不可用的情况，并且通过限制流量和重启OCP以及其主机上的agent能够暂时解决问题，但流量限制解除后问题又会重现。您提到的日志中有“no memory or reach memory limit”的错误提示，即使增加了metadb的内存也未能解决问题。根据这些信息，我们可以分析以下几个方面：

  1. 网络流量异常：根据 [5]和 [7]，当遇到网络流量异常飙高的情况时，首先需要检查是否是由于短期业务量大导致的。如果是短期业务量大导致的流量异常，通常等待业务量恢复正常后，告警会自动消除。然而，您提到的情况似乎并不符合这一模式，因为流量限制解除后问题仍然存在。

  2. 内存问题：您提到的日志错误提示表明OCP可能遇到了内存不足的问题。尽管您已经尝试增加metadb的内存，但问题依旧存在。这可能意味着问题不仅仅在于metadb的内存配置，还可能涉及到OCP本身的内存使用情况或其他组件的内存消耗。

  3. Agent的影响：根据 [6]，OCP V4.3.0版本修复了agent内存泄漏的问题，这表明之前的版本中确实存在agent内存使用超出预期的情况。虽然您的版本已经修复了这个问题，但如果重启agent后流量有所下降，这可能暗示agent在运行过程中对网络流量有一定的影响。

综上所述，虽然您描述的现象可能与OCP本身的设计有关，但从您提供的信息来看，很难断定这是一个明确的产品缺陷。更有可能的是，当前配置或环境中存在某些特定条件导致了这一问题的发生。建议您进一步排查OCP及其相关组件（如agent）的内存使用情况，并检查是否有其他因素（如网络配置、其他运行的服务等）影响了OCP的正常运行。如果问题仍然无法解决，建议联系OceanBase的技术支持团队进行深入诊断。

检索到的文档如下:

  1. 通过 OCP 部署 OceanBase 集群
  2. 新建集群
  3. 主机规划
  4. 集群性能诊断
  5. ob_host_net_send_percent_over_threshold OB 服务器网络发送带宽使用率超限
  6. OCP V4.3.0
  7. ob_host_net_recv_percent_over_threshold OB 服务器网络接收带宽使用率超限
  8. OCP V3.3.1
  9. OCP V3.3.4
  10. 仲裁服务功能
#4

有可能触发了某个bug，ocp-server内存分配多少

#5

metatdb 的 memory_limit 是120G，system_memory 10G，meta租户20G，sys租户20G，ocpminor租户50G，ocp应用分配好像12或者15G。这套OCP接管三百多个租户，有些租户数据量都很大，iftop查看目前OCP所在主机网络流量达到几G多

#7

ocp架构是啥样的。一般管控的多了，ocp也是需要扩容集群规模的

#8

当前OCP点击一个集群出现size overflow错误，OCP日志中也是这个错误，这个需要调整什么

#9

根据您描述的情况，OCP点击集群时出现了“size overflow”错误，并且在OCP的日志中也记录了相同的错误信息。此外，您提到metadb的memory_limit设置为120G，system_memory为10G，meta租户分配了20G，sys租户分配了20G，ocpminor租户分配了50G，而OCP应用本身分配了大约12或15G的内存。这套OCP系统目前管理着超过300个租户，并且一些租户的数据量较大。使用iftop工具检测发现当前OCP所在主机的网络流量达到了几G。

针对“size overflow”错误，这通常意味着OCP在处理数据时超过了其预设的大小限制，可能是由于内存不足或数据结构设计不当等原因导致。考虑到您管理的租户数量较多且部分租户数据量较大，这可能会加重OCP的内存负担。以下是一些可能的解决方案：

  1. 增加内存分配：根据您提供的内存分配情况，OCP应用本身的内存分配可能相对较少。您可以尝试增加OCP应用的内存分配，以确保其有足够的资源来处理大量的租户数据。具体来说，可以考虑将OCP应用的内存分配增加至20G或更高，以满足更高的内存需求。

  2. 优化数据存储和查询：如果增加内存分配后问题仍然存在，那么可能需要从数据存储和查询的角度进行优化。例如，可以检查是否存在不必要的冗余数据或低效的查询语句，并对其进行优化。此外，还可以考虑使用更高效的数据结构或算法来减少内存占用。

  3. 检查网络流量：您提到当前OCP所在主机的网络流量达到了几G，这可能会影响OCP的性能。建议检查是否有异常的网络活动，并采取措施限制不必要的网络流量，以减轻OCP的负担。

  4. 升级OCP版本：如果您当前使用的OCP版本较旧，那么可能存在已知的bug或性能瓶颈。建议升级到最新版本的OCP，以获得更好的性能和稳定性。

  5. 联系技术支持：如果上述方法均无法解决问题，建议联系OceanBase的技术支持团队，他们可以为您提供更专业的建议和支持。

希望这些建议能对您有所帮助。如果还有其他问题或需要进一步的帮助，请随时联系OceanBase的技术支持团队。

详情请参考:

  1. 主机规划
  2. OCP 服务器配置要求
  3. 主机资源

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#10

麻烦发下当前ocp部署架构，例如ocp meta数据库是否和ocp-server分开部署，ocp meta数据库架构，
ocp纳管了几个集群，几个节点等

另外发下ocp-server.log

#11

单机的，meta和应用部署在一台机器上，metadb也是单机的

#12

单机OCP和metadb。没有分开部署，ocp接管了27个集群，343个租户，100个主机，日志稍等

#13

从描述看这个ocp比较繁忙，纳管的规模已经不小了
1.发下报错时的observer.log
2.查看下ocp主机的内存，cpu使用情况以及ocp_meta，ocp_monitor租户的内存，cpu使用情况，看是否紧张
3.建议数据库和ocp应用分开部署，并且数据库不要使用单节点

#14

metadb直接扩容没问题吧? 另外，metadb支持升级吗，我看当前版本是4,1.0可能不太稳定，先升级到4.2.1.8

#15

meta租户可以扩容，数据库也可以升级，
升级参考
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001431732

#16

好的，我晚上在测试环境试一下升到4.2.1.8

#17

老师，我把ocp-server.log日志信息单独发您

#18

老师，明天方便钉钉沟通下吗，我把日志提供给您

#19

结论：ocp431已知问题，建议升级到432版本

绕过方式：关闭流量高的集群SQL采集开关

关闭后ocp server 流量由峰值5～6GB降低为200～300MB。

1 个赞
#20

谢谢旭辉老师以及OCP的老师