导数内存占用高

培训中心
#1

【产品名称】oceanbase

【产品版本】3.1.1

【问题描述】使用OBD部署最新单机版本环境，配置16C64G，想测试下TPC-C，给新租户配置了40G的内存，并且在导数节点按照文档上限速，设置freeze百分比和合并并发等参数，结果300仓的数据都导不完就内存不足了，也就是下面的TOTAL_GB一直上涨（把所有能能调的参数都试过了，没用），后台报minor freeze all/partial failed，do minor freeze fail，Fail to merge partition等错误。

MySQL [oceanbase]> SELECT /*+ READ_CONSISTENCY(WEAK),query_timeout(100000000) */ TENANT_ID,IP, round(ACTIVE/1024/1024/1024,2)ACTIVE_GB, round(TOTAL/1024/1024/1024,2) TOTAL_GB, round(FREEZE_TRIGGER/1024/1024/1024,2) FREEZE_TRIGGER_GB, round(TOTAL/FREEZE_TRIGGER*100,2) percent_trigger, round(MEM_LIMIT/1024/1024/1024,2) MEM_LIMIT_GB FROM gv$memstore WHERE tenant_id >1000 OR TENANT_ID=1 ORDER BY tenant_id,TOTAL_GB DESC;

±----------±----------±----------±---------±------------------±----------------±-------------+

| TENANT_ID | IP | ACTIVE_GB | TOTAL_GB | FREEZE_TRIGGER_GB | percent_trigger | MEM_LIMIT_GB |

±----------±----------±----------±---------±------------------±----------------±-------------+

| 1 | 127.0.0.1 | 0.18 | 0.18 | 0.67 | 26.45 | 6.72 |

| 1001 | 127.0.0.1 | 19.08 | 40.67 | 4.10 | 991.75 | 41.01 |

±----------±----------±----------±---------±------------------±----------------±-------------+

尝试换一个配置更高的服务器（104C256G），设置租户内存80G，是可以把300仓的数据导进去，但是导完后手动做minor freeze,major freeze，重启等，内存还是不释放，这是转储失败还是本来就这样？按照我的理解，无论哪个成熟数据库。导个300仓（30G的数据），也不会消耗这么大的资源。有大神帮忙解答吗

2015×1095 116 KB

1 个赞
大数据量的SQL文件导入ob中报错内存不足
#2

看这个


https://mp.weixin.qq.com/s/DYTOri_Cq6XWKOmZc5EeBg

1 个赞
#3

没有的，这些参数我都调整过了，租户写速度限速，加大合并的并发，缩小触发合并的内存比例都没用的。

还有就是请看第二个例子，我使用资源大的机器，即使导进去成功了，手动做freeze操作也没用

#4

其实得看ACTIVE的内存，这种才是租户实际使用的内存，TOTAL一般上去就不会掉下来除非重启

#5

就是实际使用的，

我就不明白，30G的数据导入能把60G的机器内存搞满，而且导入速度已经限制了，租户流量也限制了，都搞不定。

每次导到150仓左右开始FREEZE日志就报FREEZE FAILD，然后内存就开始慢慢打满了。

Worker 001: ERROR: No memory or reach tenant memory limit

Worker 012: ERROR: No memory or reach tenant memory limit


#6

文章中的参数你能都发一下吗？


跟数据量无关，跟写入速度有关。只要转储速度比写入速度快，就不会报错。进一步降低转储触发阈值和提升转储并发。观察一下cpu和io

#7

这个说法不对的，转储成功会使total值下降。

#8

以及发一下obd部署用的配置文件，内存很大的时候，启动参数跟内存很小时启动参数也不一样

#9

oceanbase-ce:

 servers:

  # Please don't use hostname, only IP can be supported

  • 127.0.0.1

 global:

  home_path: /home/observer

  # Please set devname as the network adaptor's name whose ip is in the setting of severs.

  # if set severs as "127.0.0.1", please set devname as "lo"

  # if current ip is 192.168.1.10, and the ip's network adaptor's name is "eth0", please use "eth0"

  devname: lo

  mysql_port: 2883

  rpc_port: 2882

  zone: zone1

  cluster_id: 1

  datafile_size: 8G

  # please set memory limit to a suitable value which is matching resource. 

  memory_limit: 60G

  system_memory: 2G

  stack_size: 512K

  cpu_count: 16

  cache_wash_threshold: 1G

  __min_full_resource_pool_memory: 268435456

  workers_per_cpu_quota: 10

  schema_history_expire_time: 1d

  # The value of net_thread_count had better be same as cpu's core number. 

  net_thread_count: 4

  sys_bkgd_migration_retry_num: 3

  minor_freeze_times: 10

  enable_separate_sys_clog: 0

  enable_merge_by_turn: FALSE

  datafile_disk_percentage: 20

  appname: test03

obproxy:


 servers:


  • 127.0.0.1


 global:


  listen_port: 2885


  home_path: /home/admin


  # oceanbase root server list


  # format: ip:mysql_port,ip:mysql_port


  rs_list: 127.0.0.1:2883


  enable_cluster_checkout: false


  # observer cluster name, consistent with oceanbase-ce's appname


  cluster_name: test03


#10

如下这个是资源的监控，起实例直接占用近10G，然后啥都不做内存持续上涨，在发起导数的瞬间直接升到37G，导数进程占用6G（但还是涨的很高），然后在15分钟左右还可以freeze回收内存，当到达一定数据后就一直网上涨了，最终Worker 000: ERROR: No memory or reach tenant memory limit导数失败。 loadWorkers=8导数速度真不高~而且还对租户做限制了

#11

CPU和IO

#12

是不是数据文件配置的太小了，只有8G？

datafile_size与 

datafile_disk_percentage
 同时配置时，以datafile_size配置项设置的值为准。

1 个赞
#13

又学到了。。。

#14

真的是这个原因，感谢大哥！

#15

这个内存监控图 是主机层面的内存监控图，取的是 /proc/meminfo 或者 free -g 。 从这里分析思路是不对的。

OBSERVER 进程起来后设计上就是要把主机大部分内存占住（memory_limit 或 memory_limit_percentage控制）。当然实际上一个刚启动的observer进程对内存的占用没有那么快，但最终就是应该占住不释放。所以不要看这个内存监控。

要到ob内部去看 gv$memstore 的数据。通过 dooba 看也行。 或者安装 obagent 配合 grafana 可以看图形曲线。


#16

gv$memstore也不准，，经常从gv$memstore查出来没有使用满，但是实际上主机的内存已经被占用完了，而且TOP看还是observe进程占用的

#17

那是的，因为内部统计是异步的，租户内存越小，内存消耗速度越快，这个会感觉越不准。