【案例67】Npart批量启动服务卡顿严重分析过程

本文主要是介绍【案例67】Npart批量启动服务卡顿严重分析过程，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

问题现象

通过Npart启动NC服务，发现只启动一个，大概3min左右即可启动成功。但是批量启动服务需要几十分钟才可以把服务启动成功，启动卡在获取“wenjian”图标处。

绕过Npart直接写脚本并行启动相关服务，发现也需要30min+

问题分析

查看nc-log.log发现有大量报错：获取参数FIP020失败，根据CPU个数获取最大线程数，请检查参数配置。

怀疑是JVM参数配置异常导致，故检查JVM参数发现现有参数配置

### xxx为打码路径，请找自己环境的路径-server 
-Xmx8196m 
-XX:MetaspaceSize=512m 
-XX:MaxMetaspaceSize=1536m 
-Dsun.reflect.noInflation=true 
-Dsun.reflect.inflationThreshold=0 
-Djava.awt.headless=true 
-Duser.timezone=GMT+8 
-Dlog4j.ignoreTCL=true 
-Dfile.encoding=UTF-8 
-Djava.lang.string.substring.nocopy=true
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/xxx/outofmemory.hprof 
-XX:+PrintGCDateStamps 
-Xloggc:/xxx/gc.log 
-Dsun.reflect.inflationThreshold=0 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/xxx/outofmemory.hprof 
-XX:+PrintGCDateStamps 
-Xloggc:/xxx/gc.log 
-Dnc.ds.conn.recordUseTrace=true

仔细排查发现下列参数加载了2次

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/xxx/outofmemory.hprof -XX:+PrintGCDateStamps -Xloggc:/xxx/gc.log

去掉相关参数，部署参数到sysconfig中，再次通过Npart批量重启发现。服务启动速度提升2倍，但也需要10min左右。 再次观察启动日志发现，启动卡在连接数据库层面。

通过checkDB脚本测试，正常应该5s钟有返回值，但是通过测试发现大概1min才会有结果返回。

查询数据库，发现数据库中有大量的ORA报错。顾问反馈数据库本身IO等有问题，最近准备重做数据库。故先不解决。

后续顾问找到了个脚本查询了应用服务器到数据库服务器创立链接的时间大概都需要40s+。

 

解决方案

把多余补充的参数去除，启动速度客户可接受。后续重做数据库，启动速度还会有所提升。

这篇关于【案例67】Npart批量启动服务卡顿严重分析过程的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---