【be存储】三节点间磁盘存储不均衡/回收站使用大

【详述】2.3.0升级至2.5.4版本三台BE节点。其中存储路径:storage/data。每个节点的大小不一,且差异巨大。show backend命令查看到的存储与磁盘实际使用也不一致。
回收站占用磁盘也很大,目前配置了参数:trash_file_expire_time_sec=600,尽快删除回收站。但是之前2.3.0版本并无该情况。

【背景】从2.3.0版本升级至2.5.4版本。
【业务影响】
【StarRocks版本】2.5.4版本
【集群规模】例如:3fe(3follower)+3be(fe与be混部)
【机器信息】CPU虚拟核/内存/网卡,例如:8C/24G/万兆

【附件】
三节点数据存储路径以及大小:
10.2.32.77:
16G /data/starrocks/be/storage/data

10.2.32.79:
45G /data/starrocks/be/storage/data

10.2.32.78:
134G /data/starrocks/be/storage/data

命令查看:


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

| BackendId | IP | HeartbeatPort | BePort | HttpPort | BrpcPort | LastStartTime | LastHeartbeat | Alive | SystemDecommissioned | ClusterDecommissioned | TabletNum | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | MaxDiskUsedPct | ErrMsg | Version | Status | DataTotalCapacity | DataUsedPct | CpuCores | NumRunningQueries | MemUsedPct | CpuUsedPct |

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

| 10002 | 10.2.32.77 | 9050 | 9060 | 8040 | 8060 | 2023-04-19 11:58:44 | 2023-04-24 14:09:47 | true | false | false | 9217 | 2.549 GB | 167.197 GB | 198.903 GB | 15.94 % | 15.94 % | | 2.5.4-1021a92 | {“lastSuccessReportTabletsTime”:“N/A”} | 169.747 GB | 1.50 % | 8 | 1 | 61.74 % | 0.6 % |

| 10003 | 10.2.32.78 | 9050 | 9060 | 8040 | 8060 | 2023-04-25 11:17:07 | 2023-04-25 11:17:07 | true | false | false | 9218 | 2.549 GB | 168.249 GB | 198.903 GB | 15.41 % | 15.41 % | | 2.5.4-1021a92 | {“lastSuccessReportTabletsTime”:“N/A”} | 170.799 GB | 1.49 % | 8 | 1 | 59.57 % | 0.3 % |

| 10004 | 10.2.32.79 | 9050 | 9060 | 8040 | 8060 | 2023-04-25 11:22:14 | 2023-04-25 11:22:14 | true | false | false | 9222 | 2.549 GB | 167.302 GB | 198.903 GB | 15.89 % | 15.89 % | | 2.5.4-1021a92 | {“lastSuccessReportTabletsTime”:“N/A”} | 169.851 GB | 1.50 % | 8 | 0 | 13.42 % | 0.4 % |

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

能统计下/data下的文件夹哪个tablet占的比较多么/data/00x1/xxx2,其中xxx2是tabletid,可以通过show tabletid xxx2看到占用比较大的是归属于那一张表的

data路径的问题以及处理了。现在问题是trash比之前2.3.0版本的大了很多。目前是通过trash_file_expire_time_sec=600尽快删除文件。是异步物化视图操作导致回收站变大吗?

04.27从2.3.0版本升级至2.5.4版本。文件数量变得异常的多。另外文件的占比也更大了。
这是其中一个be节点的trash情况。
image
其中17469的文件数量为27号升级当晚的生成的。是由于升级导致的废弃文件多吗?