回收1000次错3次，这准头你还有什么不放心的

定的凌晨2点的月度巡检闹钟响了，刚把许可服务器所有指标检查完，泡的浓茶现在还冒着热气。

闹钟震起来那一下我条件反射地伸手按掉，生怕多响一秒钟把老婆吵醒。然后摸着黑从床头柜摸手机，屏幕亮光照着脸，蹑手蹑脚地下床，拖鞋都没敢拖拉，一步一步挪到书房门口。关上门之后才敢开灯，开了之后还不放心，回头看了一眼卧室方向没动静才坐下开机。这感觉就跟做贼似的，每次半夜巡检都这套流程。今天还算顺，远程连上服务器没卡顿，lmstat敲下去响应也快。我按流程把几个核心指标过了一遍，服务状态正常，日志没有异常报错，磁盘空间还够，会话数为零。一切正常之后我才敢泡了杯浓茶坐下来喘口气，因为接下来要趁这个没人的空档把几个平时不敢动的设置顺手优化一下。

第一个动手的是回收超时时间的浮动范围。之前我设的是固定25分钟空闲回收，但上个月的数据显示有好几个用户卡在24分钟左右动一下鼠标然后接着放空，人为卡着阈值。这次我把阈值从固定值改成了20到35分钟之间的随机值，每次检测时脚本自己从范围里抽一个数，让人没法掐着点来。但这个设置白天绝对不能动，因为改完要重启服务的策略加载，重启那十几秒会话会抖一下，白天几百号人在线你搞这个就是找骂。只有凌晨这个点池子里全是空的，随便你怎么重启都没人知道。我改完等了两分钟确认服务重载成功就放心了，这改动下个月应该能堵住那些卡时间的人。

第二个优化是把不同Feature的回收阈值拆开设了。以前全局统一25分钟，但不同的模块使用习惯完全不一样，有的交互式的点一下等一分钟就想半天，有的是提交任务后就放后台跑。这次我把检测逻辑改成了按Feature类型分别配置，画图类20分钟，仿真类45分钟，后处理类30分钟。这个拆分也是只有凌晨才能干，因为要改配置文件并重载，白天做会断掉正在运行的会话。这次我把配置分段写清楚了，用条件判断匹配不同的Feature名称。改完重载之后我特意跑了个测试命令确认回收规则已经生效了。

第三个优化是把日志轮转策略重新调了一下。上个月的debug.log已经撑到4个多G了，读写都在拖慢服务响应。以前设的是每周二凌晨切一次，但周二有时候有夜班任务还在跑，切日志的时候万一卡IO会影响性能。这次我改成每周日凌晨3点切，因为周六夜班的人最少，周天凌晨基本是绝对空档。而且我把保留周期从30天缩到了20天，因为审计要求最少保留30天但那是对审计日志而言的，debug.log这种排障用的20天足够了，省空间。这个轮转策略也是只有凌晨才敢动，因为切日志的那一刻磁盘IO会飙一下，白天有人用的时候切会影响响应速度。

最后说两个月度巡检绝对不能省略的核心检查项。第一个是授权文件完整性校验，每个月必须手工对比一下license.dat的md5值跟月初备份的那个版本是否一致，防止被意外修改或者磁盘静默损坏。我见过一个同行就是因为从来不查这个，文件坏了一个字节导致某个Feature全体不可用，查了三天才发现。第二个是检查服务器系统盘剩余空间和CPU负载趋势，把过去一个月的平均值跟峰值拉出来看一下有没有异常爬升。很多时候性能问题是慢慢累积的，你要是不看趋势只看当前值，等爆了才反应过来就晚了。

茶喝完了，检查表上所有项全部打勾。天马上要亮了，赶紧躺回床上补觉。