应用服务器重新启动的分析与总结

最新推荐文章于 2022-08-09 10:19:11 发布

软件测试King老师

最新推荐文章于 2022-08-09 10:19:11 发布

阅读量1k

点赞数

本文链接：https://blog.csdn.net/JCY58/article/details/38683105

版权

现象：经过开发人员和测试人员加班加点千辛万苦开发出的软件在用户实际使用的过程中，技术支持或者用户反馈回来在用户处实施安装的软件每隔几天需要人为的手工重新启动，或者服务器运行越来越慢的现象。

结合我自己的项目经验谈谈：这个时候我们首先要做的是：

一：查看应用服务器的日志：让你的技术支持人员或者是用户把服务器的日志发过来，比如：Tomcat日志，IIS日志,还有数据库的日志，然后拿回来对这些日志进行分析。

比如在这些日志中能看出是否有内存泄漏的提示，文件打开没有关闭的提示，端口有没有被其他程序意境占用等等。

二：检查服务器的事件查看器：看安装应用服务器的服务器上：管理工具-..事件查看器，看看服务器上最近有什么异常情况。如下图：

三：检查用户的环境：如果是在公司内部环境下没有这样的情况，那首先应该考虑用户环境的问题：比如笔者在给国内一家零售商做的无线销售软件的时候，服务器端是用 C++写的一个 service.exe程序，做成 windows服务的形式，---但是问题出来了，用户的服务器上后来安装了瑞星防火墙，能拦截和阻止这个 service.exe.后来找了半天的问题，把瑞星防火墙设置成允许 service.exe-..问题解决。甚至可以把用户服务器上的防火墙关掉看看，还有就是防火墙可能会屏蔽掉很多端口的。

四：检查数据库的日志：有一次一个系统在前几个月一直运行良好，但是后来运行越来越慢，最后终于定位到是 sql server的数据库日志满了。删除数据库日志后，程序立即恢复正常。另外根据数据库设计的实际情况附上一个sql server删除数据库日志的简单代码如下：

■清理日志的方法如下：

方法在此处省略（因为新浪的博客不支持字数太多，所以为了节约篇幅省去了该处的代码）

五：检查 Tomcat服务器配置参数是否合理（对于java应用程序的tomcat服务器来说）

■检查了 Tomcat的配置文件 server.xml，把 Tomcat中默认的允许访问的最大数 75给改掉备注：你可以试试不修改这个这个 75的参数，然后用测试工具 loadrunner在客户端加压，看看 tomcat的日志是如何反应的。

■程序中数据库连接池配置，如下：数据库连接池配置的方式如下：修改 tomcat配置文件 server.xml，在 context标签中加上，对于大型的应用项目一定要使用数据库连接池技术。切记！（关于如何使用数据库连接池的技术大家可以到网上google一下）。

■在较大型的应用项目中，增大 Tomcat的默认可以使用的内存，需要把这个两个参数值调大。例如： JAVA_OPTS='-Xms 256m -Xmx512m'表示初始化内存为 256MB，可以使用的最大内存为 512MB备注：我第一次在做“昆山市企业数据交换系统 ”的时候，用测试工具模拟了一个 100个用户查询的景，测试到了凌晨 12：00的时候，tomcat报出异常，大概的意思是不能承受这么大的压力，后来调整了这个参数，但是作者本人的观点是采取这样的做法应该是一种治标不治本的做法。

六：要加大数据库的最大连接数如下：

■Oracle9i中默认的连接数为 150，要修改这个配置文件，需要修改 SPFILEORCL.ORA文件中的 processes的值。

■Sysbase数据库中修改：进 Sybase central--..鼠标右键选择数据库服务器 (要处理的服务器 )，然后选择右键菜单中的配置选项-..修改其中的 number or user connetions。

七：分别查看服务器和数据库服务器的内存和 CPU使用百分率

■假如数据库 CPU资源已经耗尽，要优化 SQL语言，比如创建新索引消除全表扫描。另外看能否用简单的查询语句代替复杂的查询语句。

■有一次在做一个加密软件的时候，发现 CPU和内存的使用都很高，测试人员把这个问题立即反馈给程序开发人员，结果是：程序中存在内存泄漏的严重缺陷。

建议：如果用户的服务器硬件配置不高的话，可以首先更换性能更高的，增加服务器的内存，或者替换高速大容量的硬盘。

八：从代码方面进行优化，比如：连接池的数据库连接没有进行释放，例如：

try{
SqlConn sqlconn=new SqlConn();
改成

SqlConn sqlconn=new SqlConn();
try{
..
}finally{
sqlconn.dbClose();
}

说明：关闭数据库的连接要一定放到finally中。

九：使用白盒测试工具：如果把第九条认为是人工审查代码的话，让开发人员用一些白盒测试工具 JProfiler或者 OptimizeIt看时候能定位到具体的哪些代码有问题。

十：设计上的不合理性：比如大量的业务操作同一张表，比如在做 Loreal系统的时候：销售、入库，进货，订货，退货，退库等等都操作同一张表 transactionlog（大量的核心业务全部操作同一张表）,当并发用户较多的时候，数据库服务器无法处理无法及时处理用户的请求，最后只有停止提供服务（我也亲身经历过的项目）。

总结：假如如果要调整服务器的性能，那么如下优先的原则是：硬件问题-..网络问题-..应用服务器，数据库配置的问题-..源代码数据库脚本的问题..系统设计的架构问题。

最后，补充二个案例如下：

案例分析一

现象:数据库CPU资源已经耗尽,大量任务位于运行队列(vmstat)

诊断步聚:

1、TOP命令，查看是否有明显过高使用CPU的进程。

2、检查进程数量,发现进程数较平时偏多，判断是数据库或应用出

了问题，导致任务无法完成，不断累积，从而出现大量队列等待。

3、查看等待事件(v$session_wait)。

4、捕获相关SQL

5、查看执行计划

6、创建新索引消除全表扫描，问题解决