LOAD DATA疑似没有走旁路且内存不回收

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OceanBase
【 使用版本 】5.7.25-OceanBase_CE-v4.3.5.2 - Mysql租户
【问题描述】串行执行LOAD DATA语句，添加了hint： /*+ direct(true,1024) parallel(16) */但是运行时租户内存占用迅速提升到90%左右且执行结束后没有下降。查询select * from oceanbase.gv$session_longops也没有任何结果，像是没有走旁路。用JAVA并行的执行LOAD的时候如果两张表都比较大就会出现No Memory or reach tenant memory limit的报错。
【复现路径】

  1. 基本信息：大概90张表、100G数据，表没有任何索引自增列等，且字段均能一一对应。测试时各表均为空表。
  2. 大致操作：
    (1) 重启数据库：后台obd cluster restart deploy_name重启，然后ocp-express查看租户内存就5%左右。
    (2) 执行批量导入脚本：就是批量调用以下命令，执行也都是成功的，大概一个小时左右：
    LOAD DATA /*+ direct(true,1024) parallel(16) */
      from files (
        location = '$MY_LOCATION',
        format = (
              type = 'csv',
              line_delimiter = '\n',
              field_delimiter = 0x01,
              parse_header = false,
              skip_blank_lines = true,
              EMPTY_FIELD_AS_NULL = true
        ),
        pattern = \"$MY_FILENAME\"
      )
      INTO TABLE $TABLECODE"

(3) 观察后台ocp-express情况发现内存迅速飙升至90%左右且运行结束后不下降。

9b5d49c2-1392-401e-9f95-a05f19f004c6
9b5d49c2-1392-401e-9f95-a05f19f004c61180×536 21.7 KB

(4) 执行过程中查询select * from oceanbase.gv$session_longops结果为空。这个操作我是看社区里有相关问答，不知道当前版本是否适用或者有其它判断是否旁路的办法。

按照我的理解旁路导入应该不会对内存有这么大影响，不知道我的判断对不对？我的执行语句有什么需要修改的嘛？

1 个赞
#3

这个租户的内存配置是怎样的？sys租户下查询看下

SELECT c.TENANT_ID, e.TENANT_NAME, f.SVR_IP,concat(c.NAME, ': ', d.NAME)`pool:conf`,concat(c.UNIT_COUNT, ' unit: ', d.min_cpu, 'C/', ROUND(d.MEMORY_SIZE/1024/1024/1024,0), "G") unit_info FROM DBA_OB_RESOURCE_POOLS c, DBA_OB_UNIT_CONFIGS d, DBA_OB_TENANTS e ,DBA_OB_UNITS f WHERE c.UNIT_CONFIG_ID=d.UNIT_CONFIG_ID AND c.TENANT_ID=e.TENANT_ID AND e.TENANT_ID=f.TENANT_ID AND c.RESOURCE_POOL_ID=f.RESOURCE_POOL_ID ORDER BY c.TENANT_ID;
1 个赞
#4

正常情况下这个应该可以查到，或者你查下这个，sys租户下查询

__all_virtual_load_data_stat
1 个赞
#5

image
image1776×196 7.19 KB

单节点，配的10C21G的

1 个赞
#6

你再导入测试下，导入时反复查询这两个视图

业务租户下查询 gv$session_longops
sys租户下查询 __all_virtual_load_data_stat
1 个赞
#7

10c 开16个并行也不合适，开8个吧

2 个赞
#8

我清空数据重新导入了一张表，大小7.7G，过程中持续刷新这两个都是空的。(还是16并行度在跑，8C我再试一下)。我这边连接的是2881端口有影响嘛？

1 个赞
#9

没有影响

1 个赞
#10

我并行度改成8之后稍微有所改观，但是上升的还是挺明显的，如果导入所有表还是会拉满。我direct的参数需要修改嘛，比如true改false，或者加上full？从视图查询的结果来看还是没有走旁路，是有什么配置需要修改嘛，我理解旁路应该是直接进SSTABLE不会有这么大的内存消耗的？

image
image1216×540 29.6 KB

2 个赞
#11

这个视图我理解是非旁路的LOAD也会在里面的？但是我们执行的时候一直是空的。我们的连接串是：/home/oceanbase/oceanbase-all-in-one/obclient/u01/obclient/bin/obclient -h$MY_HOST -P$MY_PORT -u$USER -p$PASSWORD -D $DATABASE -e "$bulkLoaderSql" ，然后是yvt_tenant租户的yvt用户(非root)，不知道这里有没有权限问题？

1 个赞
#12

不需要改，看起来语法没问题，导入期间的observer.log 压缩发下吧

1 个赞
#13

选了刚才两次导了单张表的：obd obdiag gather log yvt_cluster --from "2025-10-30 15:15:00" --to "2025-10-30 15:50:00"，前后和中间可能会有些无关的但不多。真正导入时间：第一次导入15:17:16-15:31:23；第二次导入15:35:54-15:48:17。
结果如下：
result_summary.txt (863 字节)
ob_log_local_20251030151500_20251030155000.zip (3.7 MB)

1 个赞
#14

有什么手动释放内存的方法嘛？现在LOAD结束租户的内存还是一直保持90%以上，每次重启感觉不现实。

1 个赞
#15

select * from gv$ob_memory where tenant_id=xxxx;
提供一下查询结果

1 个赞
#16

拉了相关租户的：select * from gv$ob_memory where tenant_id=1004;
结果如下：
gv_ob_memory.txt (28.7 KB)

1 个赞
#17

sys租户 查下这个

select * from __all_virtual_memory_info  where tenant_id=1004 order by hold desc limit 10;
1 个赞
#18

observer.log被回收掉了

image
image2238×220 55.4 KB

这个值调大些，日志保留多些

image
image2782×1066 185 KB

1 个赞
#19

__all_virtual_memory_info.txt (1.7 KB)

1 个赞
#20 
|tenant_id|svr_ip   |svr_port|ctx_id|label          |ctx_name         |mod_type|mod_id|mod_name       |zone |hold          |used       |count|
|---------|---------|--------|------|---------------|-----------------|--------|------|---------------|-----|--------------|-----------|-----|
|1,004    |127.0.0.1|2,882   |11    |KvstorCacheMb  |KVSTORE_CACHE_ID |user    |0     |KvstorCacheMb  |zone1|16,710,107,136|0          |7,968|
|1,004    |127.0.0.1|2,882   |2     |Memstore       |MEMSTORE_CTX_ID  |user    |0     |Memstore       |zone1|405,749,760   |405,564,120|195  |
|1,004    |127.0.0.1|2,882   |0     |MysqlRequesReco|DEFAULT_CTX_ID   |user    |0     |MysqlRequesReco|zone1|347,160,576   |346,731,712|194  |
|1,004    |127.0.0.1|2,882   |0     |TmpFileWBPBlk  |DEFAULT_CTX_ID   |user    |0     |TmpFileWBPBlk  |zone1|203,915,264   |203,814,912|98   |
|1,004    |127.0.0.1|2,882   |8     |CoStack        |CO_STACK         |user    |0     |CoStack        |zone1|145,539,072   |145,268,352|282  |
|1,004    |127.0.0.1|2,882   |0     |CACHE_MAP_NODE |DEFAULT_CTX_ID   |user    |0     |CACHE_MAP_NODE |zone1|85,311,488    |85,269,504 |41   |
|1,004    |127.0.0.1|2,882   |0     |LogGroupBuffer |DEFAULT_CTX_ID   |user    |0     |LogGroupBuffer |zone1|83,927,040    |83,886,080 |2    |
|1,004    |127.0.0.1|2,882   |5     |SqlPhyPlan     |PLAN_CACHE_CTX_ID|user    |0     |SqlPhyPlan     |zone1|74,430,720    |66,791,221 |5,740|
|1,004    |127.0.0.1|2,882   |0     |MrgMemPoolChk  |DEFAULT_CTX_ID   |user    |0     |MrgMemPoolChk  |zone1|50,393,088    |50,332,008 |3    |
|1,004    |127.0.0.1|2,882   |0     |ServerObjecPool|DEFAULT_CTX_ID   |user    |0     |ServerObjecPool|zone1|42,774,528    |42,713,088 |3    |

继续查下这个

select * from __all_virtual_kvcache_info where tenant_id=1004 order by kv_cnt desc limit 20;
1 个赞
#21

__all_virtual_kvcache_info.txt (2.6 KB)