【 使用环境 】测试环境
【 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秒）。