一、nserver服务占用率 100%,后台代理处理等待队列状态
二、大批量更新报表,导致服务器宕机
问题分析:
一、服务器应用复杂度分析
service服务器肩负这客服管理、工时管理、Teamroom项目工作室、工时报表等服务,涉及人员较广:蓝凌内部员工、服务器的客户管理员等。应用多、人员多可能会受到“代理运行限额”和 “代理限额运行时间” 限制制约;遇到并发量大的时刻可能会引起nhttp.exe无法响应,出现假死的现象。
二、NSD文件宕机根源分析
通过文件的分析,每次宕机的点都不同,但是集中在工时报表查询应用中,特别是报表预览、报表的提交操作上,可以定位是在报表统计的环节导致服务器的宕机。
三、报表统计代码分析
1、 统计单一报表:团队级别的统计无宕机现象;增加到中心级别,华南大区,10次中,导致宕机1次;极限模式到深圳蓝凌,直接宕机。
*代码缺少对大数据量的细化,服务器和SQL间交付的数据过于庞大,容易引起宕机发生
2、并发统计报表:并发10个团队级别的报表,无宕机现象;并发20个,服务器nserver.exeCUP占用率100%,服务器假死。
*对报表的统计采用单线程,一次统计创建一个ODBC连接,并发创建,可能导致windows操作系统响应超时,容易发生假死现象,等同于宕机
初步解决方案:
方案一: ODBC连接方式 调整为 ADO方式 (ADO访问速度快,内存所需小)
方案二:调整报表发布方式,优化资源配置,队列的形式
创建 - 注册报表服务 - 报表服务调度 - 发布报表
方案三:优化ODBC连接方式,增加令牌,设置最高并发数;如超最高并发数,转为注册报表服务,以报表服务调度规则生成报表;优化查询中select * from table的大数据请求,减少非关键数据的交互时间
最终方案:
1、优化domino服务器配置,增加“代理运行限额”
2、调整报表统计发布方式,由“直接返回”调整为 “注册报表发布服务-报表服务调度-返回报表”的后端发布模式。合理调配资源,保证服务器多应用的正常运行。引入服务队列的概念,“先进先出”进行报表的发布。定期定量进行报表的发布,减少nhttp的负载。
3、增加报表视图端的批量更新报表功能,方便进行报表的更新操作
4、优化报表发布逻辑,将统计集合分解为小颗粒,进行统计,减少与SQL间的数据交互。支撑“极限模式”级别的统计。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞4
添加新评论2 条评论
2015-01-15 17:12
不过我感兴趣的是提到的“服务队列”概念。我也考虑
2012-09-27 10:49
不过我感兴趣的是提到的“服务队列”概念。我也考虑过一段时间,不过当时因为项目时间原因,没有实际去实现。