前言：
在企业中，出于数据安全和应用高可用，很多软件和企业会对工程文件、数据库等做自动备份和应用容灾等。一份数据或者文件会保留到很多地方，虽然满足了安全性的需求，但是会因为保存数据区间太久造成占用大量的存储成本。最凑巧的是，像我这种大怨种，刚好碰到大客户审核，因历史文件太多，造成系统卡顿，差点损失1000万的单子。
随着数字化建设的不断开展，在深入应用阶段，会发现，这些备份文件会特别大，不仅占用磁盘空间，并且影响磁盘I/O。本次，已帆软report软件为例说说历史文件清理的必要性。
一、需求起源
1.1业务场景
帆软report 升级至10.0以上版本后，其实稳定性已经高了非常多了，而且拥有宕机自启动功能。这得益于重构了产品，采用了新的引擎。但好像目前软件应对卡顿这个问题一直没有好的办法。好巧不巧，最近有次大客户审核，发生了一场持续3小时左右的系统卡顿。那真的是“王德发"。最可恶的是，后台没有任何报错，这对排查问题增加了一个level。卡顿阶段的后面日志是这样的。只看到满屏的debug日志在疯狂输出。
1.2需求分析
说实话，我也做过了很多关于帆软的项目，自认为在这块拥有很丰富的经验。但是因为这次后台没有报错，导致我第一次慌了。后面经过冷静分析和同事沟通发现，这个兄弟把正式环境的Debug模式开启了，因此后台才会疯狂输出日志。但是最凑巧的是，我们的服务器刚好是超融合的。相信很多企业都是这样，超融合的服务器存在一个很大的I/O问题，就是I/O性能相当较低，挂载固态硬盘成本高。因此当大量的日志写入磁盘，会导致系统卡顿，进而影响使用。如下图所示是我整个分析过程。
二、解决方案
2.1 降低I/O瓶颈
其实说实话还是第一次遇到 I/O瓶颈的问题，因为现在的服务器的I/O性能都能满足系统的应用，当初排查问题的时候都没往这块去思考。但正是犯了经验主义的错误，这次想记录下来分享给大家，希望大家下次遇到类似问题，能有所帮助。
在上面提到了I/O瓶颈的处理方案：
1、收回debug模式权限（已收回）
2、给服务器配置固态硬盘，提高读写能力
3、使用linux系统，对文件处理速度会快且友好
4、缩短保存企业微信推送消息文件周期，减少至1个月内
2.2病根下手
其实这次的I/O问题和帆软report这款软件的机制有一定的关系，因为在做企业微信消息推送的时候，每推送一次消息就会生成一个消息文件来保持历史消息记录。整个前端展现逻辑很优秀，也为我们企业的数字化建设提供了一个很好的抓手。因此我们企业应用的非常深入。如下图所示，企业微信已经被推送消息占满。
假如上面那个图片不够震撼的话，我给你说一组数据，我们一个月企业微信推送消息文件就有60G ，60多万个文件。因此搭配上低I/O性能的磁盘，真的是有你难受的。
三、一句代码，药到病除
因为经过业务分析，其实业务对历史推送消息的需求量不大，推送提醒其实更多的是实时性，这也是为啥会生成这么多消息文件，因为推送频率高，实时性高。
但对历史消息要求就不高，当然我们在实际应用中，可根据自己的需求来自定义删除的文件。如下所示用来删除帆软report 30天前历史文件的效果。
3.1代码
FORFILES /p D:\WebReport\WEB-INF\schedule /s /D -30 /C "cmd /c DEL /q @path "3.2代码阐述
FORFILES /p D:\WebReport\WEB-INF\schedule /s /D -30 /C "cmd /c DEL /q @path "
其中D:\WebReport\WEB-INF\schedule代表你需要删除的文件位置，后面的/S代表会遍历删除D:\WebReport\WEB-INF\schedule下面的子文件夹里面的文件，因此我们在写路径的时候只要写大目录即可。
/D -30代表删除创建时间在30天之前的文件，这里面的30我们可以根据自己的需求更改，如更改成20就是删除20天的文件了。
3.3应用
按照需求修改好代码后，我们另存为bat格式的文件，然后用Windows的任务计划程序，调用对应bat脚本就能定时执行了，再也不用操心历史文件太多带来的I/O问题了。
好了，后续大家还有任何疑问，欢迎留言讨论，希望你们不要再去踩一遍我的坑了，在升职加薪路上，越走越顺~