昨天早上刚到办公室，就接到客户的电话说其某台小型机的CPU负荷一直保持在90以上，告警短信发个不停，一直没有间断过。该服务器是一台IBM的小型机，性能应该还是不错的，出现这样的情况确实不太正常。登陆上小型机去TOPAS跟踪了一段时间，发现KERNEL主要保持在10-20之间，但是USER就一直保持在50-70。到底是什么用户进程耗费了那么多的CPU资源？该服务器是数据库服务器，上边运行的是SYBASE数据库。登陆到数据库上进行SYSMON，看到IO并不繁忙，但是CPU确实使用率比较高。跟踪观察到的现象级初步判断：1、数据库目前没有什么系统慢跟IO没有太大关系，WAIT IO也几乎接近于0。2、服务器应该主要都是在做计算型的操作。3、服务器上并没有部署有其他应用，就是数据库一个应用而已。
怎么回事？什么时候开始的呢？服务器发生了什么变化？经过与管理员沟通，发现昨晚该服务器对应的业务系统进行了程序更新的操作。按照以往的经验，估计是程序有问题了，而且从监控结果上看，IO不忙，也没有看到有大面积的阻塞，那数据库中实际上并没有存在什么大量的操作。那么，还有什么可能会产生这样的影响？“定时刷新、更新”类型的操作可能会有重大嫌疑。于是，立刻找到昨晚进行程序更新的人员，经过了解，昨晚更新的程序确实有包含一个会定时去检查接口状态，并从数据库读取数据送上接口的操作，并且频率设置是放在数据库的某个参数表里的。
是不是频率设置得不对，或者根本就是失效了呢？
“你们是在哪个表里进行记录执行频率信息的？我们去看看这条信息。“不查不知道，一查吓一跳，居然根本找不到那条信息，也就是说，程序失去了频率控制，由于程序写得不够严谨，造成了程序一直在不间断的往数据库发送相关打开连接、处理数据、关闭连接等相关请求。
”赶紧把频率设置好，你们本应该设置的频率是多久一次？“ 接着，赶紧把控制频率的记录插入到参数表中，将频率设置为每分钟一次。
CRT的窗口一直都在监控TOPAS的情况，在插入数据后，不到一分钟的时间，发现小型机的CPU负荷直接就回落到整体负荷在40%左右，这应该就是问题的根源了！接着又跟踪了一段时间，确实没有问题了，于是跟客户汇报了处理结果，并且召集了进行程序发布的相关人员，对此问题进行了分析、总结，并提出检查点的监控。希望，下一次这样的问题不要再出现了，希望通过这次事件的处理，开发人员都可以得到启发，认真检查好每一段代码，尽量不留下给别人可以犯错误的机会。