分类： Oracle
2009-01-09 23:15:11
某国家级别系统的压力测试
基本环境是这个样子的：
1、数据库服务器主机是IBM P595，其中的一个分区作为数据库服务器，AIX5操作系统，6个CPU，
2、Web 服务器是pc server 4CPU，
3、压力测试工具：loadrunner8.1，主要由紫光的工程师配合使用。
先说下具体的测试过程。
1、搭建测试环境
我主要负责服务器环境的搭建，首先是申请了足够的磁盘空间，因为初始测试数据大概
2、其它比如：loadrunner环境，weblogic环境的搭建，应用程序的部署，都有 专门的工程师完成。
基本环境搭建好后，我们就开始工作了。
当然数据库环境，数据库参数以及主机方面的设置是最具有挑战性的工作，因为一有设置不当的地方，系统大量的并发以及疲劳测试，很快就会在测试系统中体现。
首先想说下测试过程中遇到的主要的系统问题。
在weblogic端建立了500连接池，这个weblogic启动的时候就与数据库建立了连接。而连接池的作用就是在大并发的情况，避免应用程序总是频繁的连接数据库，而直接在web端缓存500个连接，即使应用连接关闭，在web服务器端仍然保持该连接，以备下次应用程序连接时使用。
因为应用程序的连接方式通过web服务器与数据库连接，因此在三层构架中，一般数据库端应该配置为专用模式，配置共享模式也发挥不了应有的作用，并且就oracle本身来说也不推荐使用共享服务器模式，会导致bug吧。
在测试前，修改了部分数据库参数：
#启用hash连接
hash_join_enabled=true
#缓存游标的数量
session_cached_cursors=30
#单个会话同时打开的游标数
open_cursors=500
#数据库最大连接数,测试要求的并发数为800
Processes=800
#物化视图查询重写功能,该参数控制的是查询基表的时候是否首先考虑查询相关的实体化视图。
query_rewrite_enabled=true
#内存等相关参数如下,按照默认值
Db_cache_size=
Shared_pool_size=
Log_buffer=
Large_pool_size=
Java_pool_size=
测试的总体过程还算是比较顺利的，我想谈下在测试过程中遇到的一些问题。
在启动weblogic服务器过程，出现如下错误：
TNS-12500: TNS:listener failed to start a dedicated server process
TNS-12540: TNS:internal limit restriction exceeded
TNS-12560: TNS:protocol adapter error
TNS-00510: Internal limit restriction exceeded
IBM/AIX RISC System/6000 Error: 11: Resource temporarily unavailable
相关该错误的参考信息：
$ oerr ora 12500
12500, 00000, "TNS:listener failed to start a dedicated server process"
// *Cause: The process of starting up a dedicated server process failed.
// The executable could not be found or the environment may be set up
// incorrectly.
// *Action: Turn on tracing at the ADMIN level and reexecute the operation.
// Verify that the ORACLE Server executable is present and has execute
// permissions enabled. Ensure that the ORACLE environment is specified
// correctly in LISTENER.ORA. The Oracle Protocol Adapter that is being
// called may not be installed on the local hard drive. Please check that
// the correct Protocol Adapter are successfully linked.
// If error persists, contact Oracle Customer Support.
第一个我想到的是否连接数不够，查下了系统中连接数只有665。
Select count(*) from v$process;---665
这个数是远远低于目前数据库设置的连接数800啊！
第二个我想到的是操作系统有限制，于是我检查了下操作系统的一些限制：
查看文件/etc/security/limits
default:
fsize = -1
core = -1
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1
这些都是没有限制。
还有一个参数是系统用户最大并发进程数。查询方法如下：
$lsattr -El sys0|grep maxuproc
发现该值为……，当时由于环境紧急，我还没有来得及查询该值，但是最后说明修改该参数后weblogic500个连接就可以正常连接。
最终在操作系统层面修改这些参数，使用root用户修改，修改后部分参数需要重启才能生效。
# 修改TCP/IP参数以及内核参数
no -p -o tcp_sendspace=262144
no -p -o tcp_recvspace=262144
no -p -o udp_sendspace=65536
no -p -o udp_recvspace=262144
no -p -o rfc1323=1
no -p -o sb_max=2*655360
no -p -o ipqmaxlen=512
# 不限制用户打开的进程数
#ulimit -s unlimited
ulimit -f unlimited
ulimit -m unlimited
ulimit -n unlimited
ulimit -d unlimited
ulimit -c unlimited
# 不限制用户资源消耗
#ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 4194304
memory(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) unlimited
# 修改用户最大进程数，默认是128
chdev -l sys0 -a maxuproc=3000，修改该参数不需要重新启动系统。weblogic连接正常。
下面是一般ORACLE应用系统，操作系统参数调整：
1）修改网络属性参数值：
no -p -o udp_sendspace=65536
no -p -o udp_recvspace=655360
no -p -o tcp_sendspace=65536
no -p -o tcp_recvspace=65536
no -p -o rfc1323=1
no -p -o sb_max=1310720
no -r -o ipqmaxlen=512
2）调整虚拟内存管理调优参数
vmo –p –o minperm%=5
vmo –p –o maxclient%=20
vmo –p –o maxperm%=20
vmo –p –o maxpin%=80
3）调整用户oracle限制参数
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 2097152
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) 20000
又报连接池连接失败，这次失败与上次失败的错误是不同的，显示的错误信息如下：
TNS-12500: TNS:listener failed to start a dedicated server process
TNS-12540: TNS:internal limit restriction exceeded
TNS-12560: TNS:protocol adapter error
TNS-00510: Internal limit restriction exceeded
IBM/AIX RISC System/6000 Error: 12: Not enough space
该错误发生的场景为，在压力测试一段时间后，突然客户端无法连接。就报了这个错误。Tns错误是一样的，但是操作系统的错误信息是不一样的，这样我就推断是操作系统的某个环境出了某个问题。
顺便说个插曲，其实神码的有位兄弟也在现场的，据说是每天付给他们6K，但是那兄弟竟然没有发现这两次的报错信息不一致 ，大概他是没有看监听的错误日志和操作系统的错误日志吧。其实查询alert日志是没有的，而这些信息并不是数据库本身的错误信息，因此这些错误信息没有记录在alert日志。因为这些错误是在客户端与数据库建立连接的时候，监听器在创建数据库专用服务器的时候产生的错误信息，因此这些信息被记录在$ORACLE_HOME/network/log/listener.log文件中。而这些错误信息在该文件中多次出现，是因为weblogic在不断的重启。
既然错误信息说空间不够，那么我就去找空间不够的地方啊，看了下操作系统磁盘空间状况：
Df –k看磁盘状况一切正常，于是我看了下topas情况,
Real,MB 16384
% Comp 97.1
% Noncomp 3.7
% Client 3.7
PAGING SPACE
Size,MB 512
% Used 99.5
% Free 0.5
发现内存使用率较高，并且交换使用率较高，几乎无剩余的交换分区了。当时就估计是内存使用率较高，而且
具体添加交换分区的方法为：
1)smit pgsp，修改paging space为
2) #mkps –s ‘
其中-s表示pp(物理分区)个数，-n表示启动后是否自动激活，-a表示是否当时激活。
当交换添加到
当时有2种声音，一个是加大内存，二是减小数据缓冲区的大小。最终决定减小缓冲区的大小到
我们可以仔细分析下交换使用率较高的原因。
AIX操作系统使用的是虚拟内存管理机制。虚拟内存空间通过操作系统的虚拟内存管理机制，管理物理内存与交换区。当程序访问虚拟内存的数据不在物理内存时，则需要将这部分数据从物理磁盘(交换区)提取到物理内存。
一般使用交换区的原因主要是物理内存不足引起的。当物理内存不足的时候，我们需要根据一定的LRU算法，腾出一定的物理内存供新的程序使用。当释放内存的时候，我们需要判断该内存是计算内存还是文件内存，如果是文件内存则直接清空该部分内存，而如果是计算内存则需要将这部分数据交换到交换分区上，这叫page out。同样当使用的数据正好在交换分区上，而不在内存里面的时候，需要将数据从磁盘上调入到物理内存，这叫page in。
因此可以断定，交换使用较高的原因为物理内存太少，计算内存太多的原因导致的。
操作系统层的故障基本主要是这些了。下面主要谈下应用方面的问题。
在应用开始前，我们针对应用的整个方案进行了分析。
这里就不方便写出具体的sql了，主要是执行计划走的不对。
比如没有走索引，应该走hash join，但是实际上走的nest loop,等等。
当然对整个方案分析后(exec dbms_stats.gather_schema_stats)，设置了正确的oracle参数值,那么oracle优化器会选择比较合适的路径，当然有时候他也会走错误的执行计划，效率不是很高。这样就需要我们人为的使用提示，强制oracle走正确的执行计划。
/*+use_hash(a,b)*/强制走hash join
/*+use_nl(b,a)*/强制走nest loop join
……
1、一位兄弟在整理数据时，将一张关键表的索引给删除了。导致和这张表相关的应用查询长时间等待。AIX系统中出现大量的AIO server进程，磁盘读写频繁。
当我跟踪相关等待的相关的sql语句后，发现全表扫描一张4500000的表，而且是几百个进程一起并发全表扫描，不死才怪呢。然后没办法，我是手工杀掉了这些进程，web服务器，loadrunner在添加了相应的索引后都重启。重启后并发一切正常。
2、oracle9206，大量并发时，当系统中出现大量null event等待的时候，其实系统应该是在等待相关的查询返回结果。
被次测试的目的是，模拟实际的场景，测出系统存在的性能问题，以及该系统相当压力下的硬件设备的配置问题。
就应用本身而言，最大挑战还是sql的优化，而前期设计的优劣也决定后期部分应用sql的效率。
