Smartbi磁盘空间告急？这篇清理指南让你轻松腾出几十GB！

最近运维同事小陈发现，Smartbi服务器磁盘空间频频告急，系统响应越来越慢，甚至定时任务失败。一查才发现，某个组件的日志文件竟然占了上百GB！事实上，Smartbi在长期运行中，各个服务组件会持续产生日志、缓存、临时文件等，若不定期清理，不仅拖慢性能，还可能引发系统崩溃。
今天，我们就来盘一盘Smartbi中哪些组件容易‘囤积’磁盘空间，以及如何安全高效地清理它们。

一、快速诊断——磁盘告警信号与定位命令

在开始动手清理之前，我们首先需要确认系统是否真的面临磁盘压力，并精准定位是哪个“大家伙”占用了空间。

当磁盘空间不足时，您可能会遇到以下情况：

• SmartBI 应用报错：在界面上传文件、执行数据挖掘任务、导出报表时失败，提示“写入文件失败”、“磁盘空间不足”或类似报错


• Tomcat 相关错误：应用无法启动，启动日志中看到"No space left on device"


• 数据库/MPP 错误：高速缓存库（如 ClickHouse）写入失败，报错“Disk is full”或“Too many parts”


• 第三方监控平台告警：服务器接入的第三方监测平台，发出的磁盘不足或占用高的告警

如果出现上面的情况，那我们基本库确认是磁盘空间问题，接下来我们将进入最重要的环节——如何安全、有效地清理各组件，既释放空间又不影响业务运行。

二、SmartBI各组件磁盘清理指南

1、磁盘查询

在各个组件的清理正式开始前，我们先简单的了解一些磁盘占用排查基础，Windows服务器可以很直观地从文件管理器中观察的，此处主要是以Linux服务器为主要说明：

（1）通过运维命令排查磁盘空间情况，检查服务器机器磁盘空间是否已满

命令：df -hl

 

（2）定位磁盘占用高的大目录

# 查看根目录下哪个文件夹最大

命令：du -sh /* 2>/dev/null | sort -rh | head -10

2、BI主应用磁盘清理

（1）Tomcat日志文件清理（最常见问题）

Tomcat应用运行过程中，catalina.out作为标准输出和标准错误输出的默认日志文件，会持续记录控制台信息。该文件在默认配置下不具备自动轮转机制，所有运行期日志均以追加方式持续写入同一文件。随着SmartBI系统长期运行，特别是存在高频操作或异常调试时，该文件会线性增长，累积占用大量存储空间。

日志文件	典型大小	是否可清理	风险等级
catalina.out	可能达到 10-100GB	可清理	低
localhost.log	通常1-5GB	可清理	低
manager.log	通常<1GB	可清理	低
host-manager.log	通常<1GB	可清理	低

如果有需要我们也可以参考一些网络资料，用shell脚本或第三方工具等实现catalina.out日志切割以及tomcat日志的定时清理。

（2）备份文件清理

备份文件积累是SmartBI系统磁盘空间占用的重要原因，通常包括以下两类：

• 系统更新WAR包备份文件清理

版本升级或补丁安装过程中，旧版本WAR包通常被重命名保留作为回滚备份。这些文件体积较大（通常200-500MB），多次更新后如果不进行清除，会有多个历史版本会累积占用数GB空间。备份文件常存放于Tomcat的webapps目录或其子目录（项目的其他指定备份目录）中。所以日常我们更新运维时，可以备份同时删除掉历史的备份，保留近期1~2个的备份文件即可。

• 自动化备份知识库文件清理

系统配置的定时备份任务（如每日知识库备份）会默认每日凌晨5点备份文件，在启动目录下的“应用名_repoBackup”。

通常自动备份的知识库文件，默认是留存30个，超出范围的会进行文件清理，删除最旧的历史备份文件。我们也可以在系统内置的【自动备份知识库】任务脚本中调整maxCount即留存的最大文件数量，尤其是一些集群环境中，计划可能随机一个节点执行，也可以按需调整单个节点上的最大备份文件个数。例如，BI有4个节点时，每个节点默认备份30个，环境总备份量可达120个，这种情况下，我们就可以考虑适当调小下单个节点的最多的备份数量，减少备份文件累计。

（3）内存溢出文件清理

在系统运行中，我们会推荐配置“ -XX:+HeapDumpOnOutOfMemoryError”这个JVM参数，当发生内存溢出时，该参数用于存储堆信息，堆文件会与系统异常时的运行内存一样大（如下文件名称通常为xxxx.hprof)，因此异常时未及时发现或清理也会导致磁盘空间大量占用。

若出现宕机问题，将文件发回支持小伙伴分析后，服务器上遗留的历史久远的堆转储文件，也可进行删除清理。

3、知识库日志表清理

系统在运行期间会持续生成各类日志文件，包括操作日志、数据抽取日志、电子表格回写日志等。系统中包含的日志表、可在【备份知识库】-【仅备份日志表】中的提示悬浮框中查看。

其中，尤其操作日志，若缺乏定期清理机制，会随系统长时间运行不断累积，导致记录数量显著增加。这不仅影响日志检索效率，还会造成知识库存储空间的不必要占用，进而影响系统整体性能与稳定性。操作日志记录了用户在Smartbi中的操作，为系统运维、排查问题提供依据。那日常我们可以如何清理操作日志报表呢？

• 在【运维设置-操作日志】打开后，可在操作区选择指定范围的日志删除。此操作不建议在系统业务时间段操作，或是仅涉及小批量的日志数据删除

• 可使用数据库工具，连接上知识库后，删除指定范围的操作日志记录，操作日志数据表结构可参考wiki文档：操作日志


• 同时也可考虑通过系统的计划任务定时清理系统操作日志，如仅保留近30天的操作日志记录，参考示例任务代码如下（如操作日志较多，如有近几年的操作日志，不建议首次清理使用该任务代码，且日常执行时请在业务空闲时间段执行）：删除系统日志脚本.txt (1.54 K)

需要说明的是，针对磁盘空间清理：

（1） 在Mysql的InnoDB存储引擎下，常规的DELETE删除操作仅为仅对数据行进行逻辑标记删除，这些被标记的空间会保留在表内供后续插入操作复用，但并不会实际缩小表文件的大小。因此，即使删除了大量数据，数据库文件占用的磁盘空间依然保持不变。

（2）TRUNCATE操作能立刻释放表内的空间，但由于InnoDB引擎的机制，这部分空间可能仍被保留在数据库系统内，未必能立即归还给操作系统。这两种方式都难以实现彻底的空间回收。

（3）最彻底有效的方法是：在停止Smartbi服务后，对目标表进行重建操作。具体流程为：

• 首先记录下原表的完整建表语句，包括所有结构、索引与约束定义；


• 随后删除原表，此操作会立即释放其占用的全部磁盘空间；


• 最后使用之前备份的建表语句重新创建该表。


• 如果需要保留数据，则必须在删除前将数据备份至临时表或文件，在重建完成后将数据导回。

4、SmartbiMpp磁盘空间清理

SmartbiMpp作为SmartBI的高速缓存库，负责存储数据，其数据存储机制具有显著特点。系统长期运行下，数据目录与核心目录会持续积累存储文件，可能占用大量磁盘空间。

（1）数据存储目录磁盘空间占用高

数据存储目录用来存储SmartbiMpp的数据文件，数据文件存储文件默认是存储在/var/lib/clickhosue，部署时如需修改数据存储目录可参考文档：安装部署SmartbiMpp 5.3 修改数据目录。若抽取数据量越大占用磁盘空间越大，故通常是建议指定数据存储目录在磁盘空间较大的目录下。

那如果数据存储空间目录占用高的情况下，我们可以如何清理呢？

• SmartbiMpp查询并清理磁盘空间，通常可能是一些“id_bak”带“_bak”后缀的抽取备份表，如何清理抽取备份表可参考wiki文档：Clickhouse中如何查询落地到磁盘中的表的大小


• 缓存库的存储目录会存储数据集抽取后的目标表，系统默认会备份存储5个目标表，可修改系统选项的 BACKUP_TAB_RETAIN_NUM=5 配置，减少备份数量。

• 另外，日常有高速缓存库监控运维需要，也可以部署SmartbiMpp高速缓存库监控管理工具，里面可对数据表空间磁盘占用进行分析：SmartbiMPP高速缓存库监控管理工具

（2）Coredump文件占用

在启用core文件打印的时候，Linux系统程序由于异常崩溃时，会记录下来的core文件，通常SmartbiMpp生成的core文件会存储在/var/lib/clickhouse/cores下。而且core文件体积通常很大（动辄数G），若未及时发现或者分析清理，core文件会堆积占用磁盘空间。当然，cores目录存储的是ch服务异常崩溃时生成的核心转储文件，而非业务数据，清理它们不会影响ClickHouse的正常运行。我们可以直接清理掉一些历史异常的core文件。

5、ETL磁盘空间清理

etl的磁盘空间占用主要是在spark处理数据存储的数据文件，spark在接收到的实验任务不会区分是否已保存，系统默认清除机制是按单个etl默认保存70条历史以及超过70天的会被清除。因每个历史实验会落地100行的数据，存储到磁盘中，ETL较多，磁盘占用较大，想减少历史这块的存储 。

• 支持在【系统选项->高级设置】中通过变量来控制保留历史的条数（此配置项针对V10.5.8及以上版本，build日期是24年及以后版本才生效）
  MAXIMUM_NUMBER_OF_MINING_HISTORY=70 表示挖掘和ETL最大历史数为70
  MAXIMUM_NUMBER_OF_JOBFLOW_HISTORY=70 表示作业流最大历史数为70

• 也可以在【运维设置-ETL/数据挖掘配置-执行引擎】中配置节点缓存数据留存天数

通过以上对各组件的分析，相信您已经掌握了SmartBI磁盘空间管理的关键技巧。磁盘清理就像给系统做定期"体检"，及时发现问题并处理，才能保障SmartBI长期稳定高效地为您服务。

 

如果您在清理过程中遇到问题，或想了解更多运维技巧，欢迎在评论区留言交流！

恭喜你已阅读完全文，来做做题巩固下学习内容，答题可赢取麦豆哦——>点击领取任务