搜集分区统计信息报租户内存不足

【 使用环境 】测试环境
【 OB or 其他组件 】oceanbase
【 使用版本 】5.7.25-OceanBase_CE-v4.0.0.0
【问题描述】对分区表搜集统计信息,报租户内存不足【租户内存24GB,内存参数均默认设置】

mysql> show create table tpch1.lineitem \G
*************************** 1. row ***************************
       Table: lineitem
Create Table: CREATE TABLE `lineitem` (
  `l_orderkey` bigint(20) NOT NULL,
  `l_partkey` bigint(20) NOT NULL,
  `l_suppkey` int(11) NOT NULL,
  `l_linenumber` int(11) NOT NULL,
  `l_quantity` decimal(15,2) NOT NULL,
  `l_extendedprice` decimal(15,2) NOT NULL,
  `l_discount` decimal(15,2) NOT NULL,
  `l_tax` decimal(15,2) NOT NULL,
  `l_returnflag` char(1) DEFAULT NULL,
  `l_linestatus` char(1) DEFAULT NULL,
  `l_shipdate` date NOT NULL,
  `l_commitdate` date DEFAULT NULL,
  `l_receiptdate` date DEFAULT NULL,
  `l_shipinstruct` char(25) DEFAULT NULL,
  `l_shipmode` char(10) DEFAULT NULL,
  `l_comment` varchar(44) DEFAULT NULL,
  PRIMARY KEY (`l_orderkey`, `l_linenumber`)
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = CONDENSED COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0 TABLEGROUP = 'tpch_tg_lineitem_order_group'
 partition by key(l_orderkey)
(partition p0,
partition p1,
partition p2,
partition p3,
partition p4,
partition p5,
partition p6,
partition p7)
1 row in set (0.01 sec)

mysql> call dbms_stats.gather_table_stats('tpch1','lineitem',degree=>'4',granularity=>'PARTITION',method_opt=>'FOR ALL COLUMNS SIZE SKEWONLY');
ERROR 4013 (HY001): No memory or reach tenant memory limit
mysql> show create table tpch1.lineitem;

在执行过程中发现SqlPx内存区占用的内存一直上涨直到租户内存不足

obclient [oceanbase]> select * from GV$OB_MEMORY order by used desc limit 10;
+-----------+----------------+----------+-----------------+-----------------+---------+-------------+-------------+
| TENANT_ID | SVR_IP         | SVR_PORT | CTX_NAME        | MOD_NAME        | COUNT   | HOLD        | USED        |
+-----------+----------------+----------+-----------------+-----------------+---------+-------------+-------------+
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | SqlPx           | 1950862 | 16659862656 | 16462243542 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | MysqlRequesReco |      18 |   115392512 |   115355648 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | SqlDtl          |    1455 |   118885952 |   107476767 |
|      1002 | 192.168.31.201 |     2882 | CO_STACK        | CoStack         |     191 |    97009664 |    96824776 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | LogGroupBuffer  |       2 |    83927040 |    83886080 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | IoControl       |      28 |    81416192 |    81368352 |
|      1002 | 192.168.31.201 |     2882 | MEMSTORE_CTX_ID | Memstore        |      25 |    52019200 |    51995400 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | CACHE_MAP_NODE  |      21 |    43696128 |    43674624 |
|      1002 | 192.168.31.201 |     2882 | WORK_AREA       | SqlAggrFuncRow  |     208 |    13828096 |    13641472 |
|      1002 | 192.168.31.201 |     2882 | DEFAULT_CTX_ID  | SqcHandlerParam |      31 |    13345216 |    13259293 |
+-----------+----------------+----------+-----------------+-----------------+---------+-------------+-------------+
10 rows in set (0.002 sec)

obclient [oceanbase]> select * from GV$OB_TENANT_MEMORY ;
+-----------+----------------+----------+-----------+-------------+
| TENANT_ID | SVR_IP         | SVR_PORT | HOLD      | FREE        |
+-----------+----------------+----------+-----------+-------------+
|      1002 | 192.168.31.201 |     2882 | 811565056 | 22381258343 |
+-----------+----------------+----------+-----------+-------------+
1 row in set (0.005 sec)

obclient [oceanbase]> select count(*) from tpch1.lineitem;
+----------+
| count(*) |
+----------+
| 59986052 |
+----------+
1 row in set (42.020 sec)

统计信息搜集把整个租户内存吃没了,因为kvcache是动态伸缩的,因此这种统计信息搜集有可能影响整体查询性能。

因此这里请问下对分区表搜集统计信息为何吃那么多内存呢(用完了十几个GB的内存)?
另外kvcache的内存能否设置一个低水位,保证kvcache的缓存不被耗尽,否则可能会影响整体查询性能(我做了个简单关联查询SQL的并发测试耗时由2.x毫秒上升至10.x毫秒左右,持续了大约20秒)。

对应时段OBServer.log日志,可以发来看看

你好,因为之前多次反复执行导致日志不容易观看,这是我刚执行发生租户内存不足时候的完整日志输出:
observer.log.bak.gz (1.5 MB)

这个有后续吗,我也是同样的问题。