SMC2.0登录缓慢

发布时间:  2016-02-04 浏览次数:  214 下载次数:  0
问题描述
SMC登录异常慢,登录后SMC首页无法显示完全,无法操作问题,该问题自动恢复。
处理过程

系统登录慢或者系统响应慢的问题一般排查步骤:

1、  登录SMC服务器检查CPU、内存和磁盘空间消耗

2、  如果CPU或内存消耗异常过大,找出主要消耗CPU或内存的进程。如果是这种情况下,一般存在内存泄漏的可能性就比较大。往往需要开发人员协助定位。而恢复手段通常可以尝试重启这个进程的服务。

3、  如果是磁盘空间消耗过大,导致可用空间不足。那么需要找出磁盘中的大容量文件。这种情况下多为日志文件。如IIS日志,数据库日志等。解决方式,也是通过尝试清理日志文件。当然日志文件增长过快,肯定伴随了一些潜在问题,如某个错误一致存在导致日志里面一直在记录这个错误。所以,如果是日志文件增长过快的问题,也需要开发人员协助定位日志文件中的具体错误问题。

4、  以上排查如果都没有发现异常,就要从会议容量,设备数量,访问数量等方向考虑。这些大容量场景下可能导致的响应速度问题,需要收集SMCtrace信息来定位原因。

5、  最后还有一种可能是数据库SQLServer的性能排查。这需要收集操作系统的事物日志来分析SQLServer都发生了些什么。

排查根源最后发现是SQLServer数据库日志异常,扩容日志操作影响了SQLServer的业务性能。排查方法是通过分析操作系统日志和截图,发现数据库事物日志记录满触发日志自增长并自动扩容日志文件。


扩容耗时2分钟左右,期间数据库不能够正常提供服务,数据读写的操作都会被挂起,体现在业务系统上正如反馈描述,反映慢,无响应或超时。数据库事物日志增长与系统容量大小和多用户操作频度有关。数据库日志自增长是正常现象。但是避免影响业务系统建议在定时巡检活动中检查和及时清除数据库的事物日志。另外解释一下该问题可自动恢复。原因是日志文件本身设置自增长,虽然日志扩容期间SQLServer性能存在影响,但是日志扩容完成后即可恢复正常数据库读写功能,系统业务性能也恢复正常。

根因

SQLServer事物日志记录已满,不定期触发了日志扩容的动作。触发日志扩容时,会锁住当前SQLServer一切业务请求。扩容期间SQLServer无法提供业务服务,对SMC系统影响就是一切涉及到数据库交互的操作都会失败或无响应的等待状态。

解决方案

Ø  临时规避方案:该问题可以自动恢复,但是存在日志扩容期间短时间的系统性能问题。

Ø  根本解决方案:虽然SQLServer事物日志是自增长的,但是缺点在于没有日志增长计划,触发日志扩容也无法控制,如果在重要会议的时候触发了日志扩容,影响还是比较大的。而SQLServer日志文件自增长设置,只能是一个默认的初始系统安装设置。部分重大局点还需要有一个合理的设定和定期巡检安排。

 

建议与总结
建议定期检查和日志清理。

END