[问题排查]磁盘空间占用异常

背景

我们经常会遇到show backends中看到的已用空间跟磁盘空间占用不一致的问题,本文主要分享下这类问题的排查思路

排查思路

1.可能做过drop database或者drop table的操作,这些操作会在内存中保留1天(一天之内可以通过recover恢复数据,避免误操作),这个时候可能会出现,磁盘占用大于show backends中显示的已用空间,内存中保留1天可通过fe的参数 catalog_trash_expire_second调整,调整方式

admin set frontend config ("catalog_trash_expire_second"="xxxx") #如果需要持久化,记得加到fe.conf中

2.可能是上面内存中的数据过了1天后进入到trash目录(${storage_root_path}/trash),该数据默认会在trash目录保留3天,这个时候也会出现磁盘占用大于show backends中显示的已用空间,trash保留时间由be的配置 trash_file_expire_time_sec(默认259200,3天),调整方式

curl http://be_ip:be_http_port/api/update_config?trash_file_expire_time_sec=xxx #如果需要持久化,记得在be.conf中配置

3.可能还存在一些bug的情况下会导致data目录占用比show backends看到的大,这个时候需要逐级目录检查是哪个tablet

starrocks的数据存储路径组成如下

storage_root_path/data/${slot_id}/${tablet_id}/${schema_hash}/${rowset_id}_${segment_id}.dat

通过如下指令一级一级定位到tablet id粒度就可以

du -sh data/*|sort -rh|head

上一步查出来的slot目录,进一步查看是哪个tablet

du -sh data/${slot_id}/*|sort -rh|head

:warning:主键模型除了关注.dat以外,还需要关注下 pk下可能有.dat,.col,.upt和index.x.x大小

然后连接leader fe(:warning::一定是leader fe),查看tablet的compaction是否正常

show tablet $tablet_id; #获取最后一列Detailcmd的值
show PROC '/xxx';

如果只有一个副本的 VersionCount 异常高(超过1000),可以考虑临时set bad恢复

ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "xxx", "backend_id" = "xxx", "status" = "bad");

如果都比较高,需要看下compaction状态如何,打开CompactionStatus字段对应的compaction url,返回结果集如下

非主键模型

{
    "cumulative point": 2,
    "last cumulative failure time": "1970-01-01 08:00:00.000",
    "last base failure time": "1970-01-01 08:00:00.000",
    "last cumulative success time": "1970-01-01 08:00:00.000",
    "last base success time": "2023-11-03 00:45:25.272",
    "rowsets": [
        "[0-25] 0 DATA NONOVERLAPPING"
    ],
    "stale version path": []
}

一般需要关注last cumulative failure time、last base failure time和rowsets

last cumulative failure time:最近一次增量合并失败的时间
last base failure time:最近一次base合并失败的时间
rowsets:当前待合并的rowset,[0-xx]表示的已经完成base 合并的,[123-123]表示的未完成任何合并的,[110-123]表示完成增量合并的,如果有大量的[123-123]前后连续的rowset,说明导入频率非常高或者增量合并没有正常进行或者合并太慢了。

如果这个分区一直有数据写入,并且最近一次的合并时间是几天前,需要查看对应be的日志,看下compaction失败的原因,通过在be.INFO中过滤对应的tablet id即可看到上下文

增量合并

grep -E 'tablet_id:${tablet_id}(.*)compaction_type:cumulative' be.INFO #需要把:${tablet_id}替换为上文检查出来失败的tablet id

base合并

grep -E 'tablet_id:${tablet_id}(.*)compaction_type:base' be.INFO #需要把:${tablet_id}替换为上文检查出来失败的tablet id

主键模型

{
    "last compaction success time": "2023-11-22 16:54:43.139",
    "last compaction failure time": "1970-01-01 08:00:00.000",
    "rowset_version": "tablet:9456211 #version:[6_0] rowsets:3",
    "rowsets": [
        "id:6 #seg:1",
        "id:7 #seg:0",
        "id:8 #seg:0"
    ]
}

last compaction failure time:最近一次合并失败的时间
rowsets:待合并的版本个数

也可以尝试手动compaction

非主键表

下文中的schema_hash为上图中CompactionStatus中对应的schema_hash

增量合并

curl -XPOST 'http://<be_ip>:<be_port>/api/compact?tablet_id=xxx&schema_hash=xxx&compaction_type=cumulative'

base合并

请谨慎操作,如果版本较多,会占用比较多的CPU、内存和磁盘资源

curl -XPOST 'http://<be_ip>:<be_port>/api/compact?tablet_id=xxx&schema_hash=xxx&compaction_type=base'

主键表

rowset_ids 为上文compactionstatus url结果中的rowsets id,例如上文中的6,7,8

curl -XPOST 'http://<be_ip>:<be_port>/api/compact?compaction_type=update&tablet_id=<tablet_id>&rowset_ids=xxx,xxx,xxx'

也可以不指定rowset id,直接指定到tablet id即可

curl -XPOST 'http://<be_ip>:<be_port>/api/compact?compaction_type=update&tablet_id=<tablet_id>'

2.5 版本支持按照分区粒度触发主键模型合并

10002 为backend id,通过show backends可以看到,10089为partition id,通过show partitions from $table 可以看到,1000000为需要合并的数据条数

admin execute on 10002 'StorageEngine.submit_manual_compaction_task_for_partition(10089, 1000000)
System.print(StorageEngine.get_manual_compaction_status())';
admin execute on 10002 'System.print(StorageEngine.get_manual_compaction_status())';
1赞

如何手动做compaction

已经补充上compaction操作方法了

我这里出现的问题是tablet下的dat文件越来越多,也不删除,但上述compaction都是正常,只是经常报warning,wait_for_version slow
有什么机制可以删除这些文件吗?哪个配置是控制定时清理这些dat文件的。可以手动删除吗?就看着硬盘空间一路上涨

您确认下选的这个tablet 的 tabletid,show tablet tabletid;然后执行show proc ,然后执行 curl Compaction status 看下结果,图二是什么监控

compaction的结果显示如下,success time很奇怪,不过再之前是正常的,我刚才重启了整个starrocks

上面的第二个图是硬盘使用量,如下图。图上最后下降了一点是因为我把采集任务全停了,并且重启了starrocks

会和服务器所在的时区有关么?服务器是在北美的,时区设的当地的,差了13小时应该。

现在又在be.warning中发现大量的找不到文件无法删除的错误,到对应574/556523/354299382 目录下查看是正常的,只有两个文件
现在完全就不能用了。。估计采集程序一开硬盘就会爆掉了。

你这个是有问题的,compaction没有正常进行,compaction完整的文件发下,另外grep compaction be.INFO* 拿下compaction所有的日志看下

空放了一晚上服务器,没有跑采集任务,现在硬盘已经降到100G的使用量了,下降曲线很明显,不过数据实际是24G,还是有差距

昨天截图的目录看起来已经正常了,只有三个文件了

然后be.INFO中关于compaction的日志如下,因为日志太多了,只拿了be.INFO的

compaction.log.tgz (5.1 MB)

关于compaction完整的文件是指什么,不知道是哪个,望大佬告知下。。

现在硬盘已经降到40G了,看起来已经基本正常,没有特别大的目录了。但这是没有运行数据采集的前提下,不知道开采集后是否会空间继续飙升。看起来就是compaction太慢造成?从晚上8点停止采集到中午12点,10几个小时才把compaction消化完?这块的优化有什么配置参数可以参考吗