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

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

　　2、检查服务器的事件查看器

　　安装应用服务器： 管理工具→事件查看器， 看看服务器上最近有什么异常情况。如图1 所示。
 

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

　　4、检查数据库的日志

　　一个系统在前几个月一直运行良好， 但是后来运行越来越慢， 最后终于定位到是SQL Server 的数据库日志满了。删除数据库日志后， 程序立即恢复正常。下面给出SQL Server 删除数据库日志的简单代码：

　　第一种清理日志的方法如下：

　　看看Tomcat 服务器配置参数是否合理(对于Java 应用程序的tomcat 服务器来说）

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

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

　　在较大型的应用项目中， 增大Tomcat 的默认可以使用的内存， 需要把这个两参数值调大。例如： JAVA_OPTS='-Xms256m -Xmx512m' 表示初始化内存为256MB， 可以使用的最大内存为512MB。

　　备注： 笔者一次在做“某市企业数据交换系统” 的时候，用测试工具模拟了一个100 个用户查询， 测试到了凌晨12：00 的时候， tomcat 报出异常， 大概的意思是不能承受这么大的压力， 后来调整了这个参数， 问题立即解决。

　　6、加大数据库的最大连接数

　　Oracle9i 中默认的连接数为150， 要修改这个配置文件，需要修改SPFILEORCL.ORA 文件中的processes 的值。Sysbase 数据库中修改： 进Sybase central， 鼠标右键选择数据库服务器(要处理的服务器)， 然后选择右键菜单中的配置选项， 修改其中的number or user connetions。

　　7、查看服务器运行状态数据

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

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

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

　　8、优化代码

　　比如， 连接池的数据库连接没有进行释放， 代码如下：
 

　　9、使用白盒测试工具

　　让开发人员用一些白盒测试工具JProfiler 或者OptimizeIt，看能定位到具体的哪些代码有问题。

　　10、设计上的缺陷

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

　　11、总结

　　假如要调整服务器的性能， 那么发现问题的排查顺序原则是： 硬件问题→网络问题→应用服务器→数据库配置的问题→源代码数据库脚本的问题→系统设计的架构问题。

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

　　案例分析一

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

　　诊断步骤:

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

　　(2)检查进程数量,发现进程数较平时偏多， 判断是数据库或应用出了问题， 导致任务无法完成， 不断累积， 从而出现大量队列等待。

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

　　(4)捕获相关SQL。

　　(5)查看执行计划。

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

　　总结： 如果数据库CPU 使用耗尽，要优化SQL 语言， 比如创建新索引消除全表扫描。

　　案例分析二

　　现象：用TOP 命令发现CPU 资源占用殆尽， 存在很多占用CPU 很高的进程， 但是内存和IO 的占用率都不高。

　　诊断步骤：

　　(1)先查看告警日志，没发现什么错误存在。

　　(2)查看占用CPU 资源很高的ORACLE 进程在做什么操作。(使用SQL 语句）， 发现占用CPU 资源很高的进程都是执行同一个SQL 语句。

　　(3)查看等待事件， 发现大都是latch free， 进一步查询发现这些等待都是由该SQL 语句产生。

　　(4)查看SQL 语句的执行计划， 发现似乎存在过多的扫描。

　　(5)在另一个同样的库上执行该计划， 发现有两个索引是不应该有的。检查表上的索引个数， 多出3个索引。

　　总结： 删除多余的索引， 将问题解决。