DR2000页面响应慢的几种案例分析

不涉及

有些已部署了DR2000的环境，在使用DR2000一段时间之后发生了页面响应慢无法打开或者功能无响应的情况 。

该问题主要有如下几种场景：

一、DR2000采集到了大量的告警

（1）查看DR2000的“故障诊断/告警分析”页面，发现页面最下方显示存在几万条告警。

（2）查看tmStat.log日志，根据如下信息，可以说明告警查询有堆积。

    目前控制器页面底部提供告警实时显示，查询逻辑为5秒钟触发一次查询。如果后台告警数据比较多，就会出现数据库响应不及时，并且数据库CPU占用异常的情况。  

二、有的微软系统TCP使用到一定数量，TCP不再继续分配。在cmd下执行netstat -ano > 1.txt命令收集运行环境TCP连接情况，发现存在大量CLOSE_WAIT状态线程，并且访问端口为80。 

    80端口为控制器访问设备的netconf接口。控制器目前的Session机制是以组件为单位建立连接，目前vxlan组件、director组件、SSM组件（选装）分别会使用一个netconf通道，因此常规场景80端口相关TCP使用为：2（vlan1/vlan4094地址）*设备数*2（单独session的组件个数）。netconf始终占用一个TCP实际是合理的，因为这样可以减少每次新建netconf连接的开销，但是个别系统就是TCP有上限。当操作系统不能够提供足够TCP连接时，由于netconf大量占用连接会导致控制器的查询无法正常建立，通过查看前后台日志可以发现大量建立查询失败的报错。

三、有的微软系统TCP使用到一定数量，TCP不再继续分配。在cmd下执行netstat -ano > 1.txt命令收集运行环境TCP连接情况，发现存在大量TIME_WAIT状态线程。

    访问数据库的1433端口存在大量的TCP连接未释放掉，系统默认TCP的TIME_WAIT时间为4分钟。在这个时间内频繁访问数据库，会滞留大量的TCP连接，导致访问Director缓慢。DR2000和SSM组件一起安装时发生过该问题，SSM组件卸载后问题消失，SSM组件侧未给出明确的定位意见。有局点没有安装SSM组件，也出现过该现象，是大量用户频繁上下线引起。 

 场景一：因为告警数据多而导致的页面响应慢问题已在部分局点发生过。当时现场都单天产生10w+告警，告警内容百分之九十以上都是接口UP/DOWN导致，因此用户需要关闭接口类告警，可以在告警分析页面配置过滤规则将不关心的接口排除掉，增加用户相对关心的接口，减少无意义的告警产生。其他用户不关注的告警也可以通过上述方法规避。 

场景二：如果TCP连接存在大量的 CLOSE_WAIT状态线程，并且访问端口为80，该问题通常发生在设备较多的环境。DR2000 ADCAM 7.3 (E0515P02)安装目录/conf/netconfCfg.properties可以配置netconf连接为短连接。关闭后将不再产生CLOSE_WAIT状态线程。（注意这种方案将会加大netconf访问设备时系统的开销，如果局点未出现问题不建议修改该配置）。

场景三：如果TCP连接存在大量TIME_WAIT状态线程，且DR2000和SSM组件一起安装，建议卸载SSM后持续观察。如果没有安装SSM组件，可以修改系统注册表项，将TCP连接的等待时间改为30秒（默认4分钟很容易造成大量TCP占用端口的情况），同时将端口数量也增加到100000以上。优化TCP配置方法如下，修改TCP注册表参数后需要重启操作系统：

（1）设置TcpTimedWaitDelay：在cmd中运行regedit命令，找到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters 注册表子键，看看有没有TcpTimedWaitDelay项。有的话直接修改，没有的话创建一个名为TcpTimedWaitDelay的新REG_DWORD值，并将此值设置为十进制30，其为十六进制 0x0000001e，即将等待时间设置为30秒。 

（2）设置MaxUserPort：在cmd中运行regedit命令，找到HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters 注册表子键并创建名为MaxUserPort的新REG_DWORD值，比如设置成65534。 

（3）设置MaxHashTableSize：在cmd中运行regedit命令，HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters注册表子键并创建名为 MaxHashTableSize的新REG_DWORD值，比如设置成65536。 

（4）设置MaxFreeTcbs：在cmd中运行regedit命令，HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/TCPIP/Parameters注册表子键并创建名为MaxFreeTcbs的新REG_DWORD值，比如设置成16000。 

    若故障现象与上述场景不完全匹配，建议收集如下信息并联系400进行下一步排查：

    1. 反馈服务器内存占用情况；

    2. 反馈iMC安装目录下\client\log下imcforeground.log日志；

    3. 双击iMC安装目录下\client\bin下tmonitor.bat,运行5min，该过程请访问访问缓慢的页面。以ctrl+c停止采集，并收集iMC安装目录下\client\log\tm*.log文件；

    4. 双击 iMC安装目录下\client\bin下jmonitor.bat，运行5min，提供截图。

    5. jmonitor里边按照这个步骤也收集下aaa.hprof文件：

    （1）切换到Mbean页签 

    （2）左树选择com.sun.management->操作->dumpHeap 

    （3）右边窗口的P0填aaa.hprof 

    （4）点击dumpHeap按钮 

    （5）等一会会弹出操作成功的提示框 

    （6）在iMC\client\bin\文件夹下生成aaa.hprof文件。   

    6. 双击iMC安装目录下\client\bin下tmonitor.bat,运行5min，该过程请访问访问缓慢的页面。以ctrl+c停止采集，并收集iMC安装目录下\client\log\tm*.log文件；

    7.反馈iMC安装目录下\client\log下blockingthreads.txt日志；

     收集完日志后可以尝试重启jserver进程恢复页面访问。