对于AIX主机的性能评估
对于AIX主机的性能评估，我们从下面的4个方面来逐一介绍：CPU、MEMORY、I/O系统和网络这4个方面来描述。
一、CPU性能评估
首先，我们还是先来看一下CPU的性能评估。下面先主要介绍几个看CPU性能的命令。
1、vmstat
使用vmstat来进行性能评估，该命令可获得关于系统各种资源之间的相关性能的简要信息。当然我们也主要用它来看CPU的一个负载情况。
下面是我们调用vmstat命令的一个输出结果：
https://www.wendangku.net/doc/a916628933.html,
$vmstat 1 2
System configuration: lcpu=16 mem=23552MB
kthr memory page faults cpu
----- ----------- ------------------------ ----------------- -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 3091988 2741152 0 0 0 0 0 0 1849 26129 4907 8 1 88 3
0 0 3091989 2741151 0 0 0 0 0 0 2527 32013 6561 15 2 77 6
对上面的命令解释如下：
Kthr段显示内容
?r列表示可运行的内核线程平均数目，包括正在运行的线程和等待CPU 的线程。如果这个数字大于CPU 的数目，则表明有线程需要等待CPU。
?b列表示处在非中断睡眠状态的进程数。包括正在等待文件系统I/O 的线程，或由于内存装入控制而被挂起的线程。
Memory段显示内容
?avm列表示活动虚拟内存的页面数，每页一般4KB
?fre空闲的页面数，每页一般4KB
Page段显示内容
?re –该列无效
?pi 从磁盘交换到内存的交换页（调页空间）数量，4KB/页。调页空间是驻留在硬盘上的虚拟内存的一部分。当内存使用过量时，会将溢出的工作组页面存储到调页空间中（窃
取页）。当进程访问一个窃取页时，就产生了一个缺页故障，而这一页页必须从调页空
间中读入到内存中。
?po 从内存交换到磁盘的交换页数量，4KB/页。如果窃取的工作也在调页空间中不存在或者已经作了修改，则写入调页空间中。如果不被再次访问，它会留在调度空间中直到进
程终止或者放弃空间。
?fr 根据页面替换算法每秒释放的页数。当VMM页面替换例程扫描页面帧表（Page Frame Table，PFT）时，它会根据一些条件选取需要窃取的页面以补充空闲列表。该条件中
包含工作页面和计算页面，释放的页面中，计算页面不产生I/O，工作页面如果数据没
有发生修改，也不需要写回磁盘，也不会产生I/O。
?sr 根据页面替换算法每秒所检查的页数。sr值比fr值高的越多，说明替换算法要查找可以替换的页面就越困难。
?cy 每秒页面替换代码扫描了PFT多少次。因为增加空闲列表达到maxfree值，不一定需要完全扫描PFT表，而所有vmstat输出都为整数，所以通常cy列值为0。Faults段显示内容（其实这段内容不需太多关注）
?in 在该时间间隔中观测到的每秒设备中断数。
?sy 在该时间间隔中观测到的每秒系统调用次数。
?cs 在该时间间隔中观测到的每秒钟上下文切换次数。
Cpu段显示内容
?us 列显示了用户模式所消耗的CPU 时间。
?sy 列详细显示了CPU 在系统模式所消耗的CPU 时间。
?id 列显示了没有未决本地磁盘I/O 时CPU 空闲或等待时间的百分比。
?wa 列详细显示了有未决本地磁盘I/O 时CPU 空闲的时间百分比。wa 的值如果超过25%,就表明磁盘子系统可能没有被正确平衡，或者这也可能是磁盘工作负荷很重的结果。
如果在一个单用户系统中，us + sy时间不超过90%，我们就不认为系统的CPU是受限制的。
如果在一个多用户系统中，us + sy时间超过80%, 我们就认为系统的CPU是受限的。其中的进程将要花时间在运行队列中等待。响应时间和吞吐量会受损害。
检查cpu，我们主要关注报告中的4个cpu列和2个kthr（内核线程）列。
在上面的示例中，我们可以观察到以下几个主要的信息：
CPU IDLE比较高，比较空闲；r列为0，表明线程不存在等待；
WA值不高，说明I/O压力不大；
free值比较大，pi，po为0，表明内存非常富裕。空闲较多。
2、sar
第二个常用的是sar命令，但是sar会增加系统的开销。当然有些情况下，我们使用sar 比较方便。
sar的输出结果与前面的基本类似，这里不再作详细的介绍，关于命令的语法，也不再作详细的介绍，我们常用的命令格式：
#sar 1 3
AIX jsdxh_db02 3 5 00C2C1EB4C00 10/24/07
System configuration: lcpu=16
17:52:26 %usr %sys %wio %idle physc
17:52:27 19 7 0 75 8.00
17:52:28 19 6 0 75 8.01
17:52:29 19 7 0 75 8.02
Average 19 7 0 75 8.01
在这里，sar命令输出的是一个整体的cpu使用情况的一个统计，统计分项目的内容也比较直观，通过名字就可以理解涵义。这里有一点比较方便的就是，在最后一行有一个汇总的average行，作为上述统计的一个平均。另外，补充说明一点的就是，一般来说，第一行统计信息包含了sar命令本身启动的cpu消耗，所以往往是偏高的，所以导致average值也往往是偏高一点的。当然，这不会对结果产生多大影响。
当我们有多个cpu的时候，而程序采用的是单线程，有时候会出现一种情况，我们检查发现，cpu总体的使用率不高，但是程序响应却比较慢。这里有可能就是单线程只使用了一个cpu，导致这个cpu100％占用，处理不过来，而其他的cpu却闲置。这时可以对cpu分开查询，统计每个cpu的使用情况。
#sar -P ALL 1 2
AIX jsdxh_db02 3 5 00C2C1EB4C00 10/24/07
System configuration: lcpu=16
18:03:30 cpu %usr %sys %wio %idle physc
18:03:31 0 0 69 0 31 0.00
1 50 50 0 0 1.00
2 0 0 0 100 0.52
3 0 0 0 100 0.48
4 0 1 0 99 0.54
5 0 0 0 100 0.46
6 0 0 0 100 0.53
7 0 0 0 100 0.47
8 0 0 0 100 0.53
9 0 0 0 100 0.47
10 0 2 0 98 0.54
11 0 0 0 100 0.46
12 11 58 0 31 0.00
13 100 0 0 0 1.00
14 0 0 0 100 0.53
15 0 0 0 100 0.47
- 19 7 0 75 8.01
18:03:32 0 0 71 0 29 0.00
1 50 50 0 0 1.00
2 0 0 0 100 0.52
3 0 0 0 100 0.48
4 0 1 0 99 0.54
5 0 0 0 100 0.47
6 0 0 0 100 0.52
7 0 0 0 100 0.47
8 0 0 0 100 0.53
9 0 0 0 100 0.47
10 0 2 0 98 0.54
11 0 0 0 100 0.46
12 39 41 0 20 0.00
13 100 0 0 0 1.00
14 0 0 0 100 0.52
15 0 0 0 100 0.47
- 19 7 0 75 7.98
Average 0 0 70 0 30 0.00
1 50 50 0 0 1.00
2 0 0 0 100 0.52
3 0 0 0 100 0.48
4 0 1 0 99 0.54
5 0 0 0 100 0.46
6 0 0 0 100 0.53
7 0 0 0 100 0.47
8 0 0 0 100 0.53
9 0 0 0 100 0.47
10 0 2 0 98 0.54
11 0 0 0 100 0.46
12 28 48 0 24 0.00
13 100 0 0 0 1.00
14 0 0 0 100 0.52
15 0 0 0 100 0.47
- 19 7 0 75 8.00
上面是分cpu统计的情况，结果应该也比较直观吧。
Sar还有其他一些比较特殊的使用方法，比如：
如果希望多个采样和多个报告，可为sar 命令指定一个输出文件，这样就方便多了。将sar 命令的标准输出数据定向到/dev/null，并将sar 命令作为后台进程运行。具体的命令格式为：sar -A -o /temp/sar_result.log 5 300 > /dev/null &
关于sar其他的一些使用方法，这里不再详述。
3、iostat
第三个可以用来使用的命令是iostat.
$ iostat -t 2 4
tty: tin tout avg-cpu: % user % sys % idle % iowait
0.0 0.0 0.0 0.1 99.8 0.1
0.0 81.0 0.0 0.1 99.9 0.0
0.0 40.5 0.0 0.0 100.0 0.0
0.0 40.5 0.0 0.1 99.1 0.8
TTY 的两列信息（tin 和tou）显示了由所有TTY 设备读写的字符数
CPU 统计信息列（% user、% sys、% idle 和% iowait）提供了CPU 的使用情况。
注意：第一份报告为系统启动以来的一个累积值。
4、tprof
使用tprof命令用于统计每个进程的CPU使用情况
# tprof -x sleep 30
该命令的输出结果可查看__prof.all文件。
此命令运行30秒钟，在当前目录下创建一个名为_prof.all 的文件。30秒钟内，CPU被调度次数约为3000次。__prof.all 文件中的字段Total 为此进程调度到的CPU次数。如果进程所对应的Total字段的值为1500，即表示该进程在3000次CPU调度中占用了1500次，或理解为使用了一半的CPU时间。tprof的输出准确地显示出哪个进程在使用CPU 时间。
在我下面的这一份示例中，可以看到，大部分的cpu时间都是被wait所占用的。这里的wait实际上是idle进程，可以表明这个系统是一个完全空闲的系统。
$ more __prof.all
Process PID TID Total Kernel User Shared Other
======= === === ===== ====== ==== ====== =====
wait 40970 40971 2998 2998 0 0 0
wait 32776 32777 2994 2994 0 0 0
wait 24582 24583 2985 2985 0 0 0
wait 16388 16389 2980 2980 0 0 0
syncd 221254 155707 31 31 0 0 0
caiUxOs 524540 2294015 3 0 0 3 0
netm 73746 73747 1 1 0 0 0
hats_nim 1671242 1220665 1 0 0 1 0
snmpd64 598258 1245291 1 1 0 0 0
rpc.lockd 639212 1728679 1 1 0 0 0
tprof 704622 2277437 1 0 0 1 0
trclogio 360524 2408625 1 1 0 0 0
trace 1523820 2523145 1 0 0 1 0
clinfo 1958102 2760945 1 1 0 0 0
sh 1572938 2285709 1 1 0 0 0
======= === === ===== ====== ==== ====== =====
Total 12000 11994 0 6 0
Process FREQ Total Kernel User Shared Other
======= === ===== ====== ==== ====== =====
wait 4 11957 11957 0 0 0
syncd 1 31 31 0 0 0
caiUxOs 1 3 0 0 3 0
netm 1 1 1 0 0 0
hats_nim 1 1 0 0 1 0
snmpd64 1 1 1 0 0 0
rpc.lockd 1 1 1 0 0 0
tprof 1 1 0 0 1 0
trclogio 1 1 1 0 0 0
trace 1 1 0 0 1 0
clinfo 1 1 1 0 0 0
sh 1 1 1 0 0 0
======= === ===== ====== ==== ====== =====
Total 15 12000 11994 0 6 0
在这里，对wait进程作一点补充说明。
在AIX 5L下，你用ps aux会发现有一些root的wait进程
#ps aux |head -20
USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND
oracle 266354 5.7 0.0 50136 27524 - A 15:40:35 0:32 oracleora92 (LOC
root 17214 3.1 0.0 40 40 - A Jul 04 24793:53 wait
root 16946 3.1 0.0 40 40 - A Jul 04 24633:59 wait
root 16678 3.1 0.0 40 40 - A Jul 04 24600:21 wait
root 53274 3.1 0.0 40 40 - A Jul 04 24397:54 wait
root 286 3.1 0.0 40 40 - A Jul 04 24371:55 wait
root 8196 3.0 0.0 40 40 - A Jul 04 24312:40 wait
root 822 3.0 0.0 40 40 - A Jul 04 24303:36 wait
root 554 3.0 0.0 40 40 - A Jul 04 24261:50 wait
root 20776 2.7 0.0 40 40 - A Jul 04 21502:46 wait
root 57372 2.7 0.0 40 40 - A Jul 04 21439:31 wait
root 49176 2.7 0.0 40 40 - A Jul 04 21423:47 wait
root 21044 2.7 0.0 40 40 - A Jul 04 21398:24 wait
root 12848 2.7 0.0 40 40 - A Jul 04 21357:07 wait
root 21312 2.7 0.0 40 40 - A Jul 04 21324:26 wait
root 12580 2.7 0.0 40 40 - A Jul 04 21293:06 wait
root 13116 2.7 0.0 40 40 - A Jul 04 21195:47 wait
oracle 344612 0.3 0.0 57588 34976 - A Jul 04 2663:08 ora_j000_ora92
oracle 430408 0.3 0.0 55908 33296 - A Jul 04 2220:57 ora_j001_ora92
wait就是CPU空闲的时候运行的空闲进程，AIX4上叫kproc。所以这个进程占用越大，表示机器越空闲。Wait进程的数量是由机器上的逻辑CPU的个数决定的，有几个逻辑CPU，就有几个wait进程.
5、ps
这个命令使用本身也比较复杂，在这里只介绍如何查看cpu占用最高的进程。使用举例如下：
#ps aux | head -25
USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND
root 17214 3.1 0.0 40 40 - A Jul 04 25578:42 wait
root 16946 3.1 0.0 40 40 - A Jul 04 25415:54 wait
root 16678 3.1 0.0 40 40 - A Jul 04 25377:03 wait
root 53274 3.1 0.0 40 40 - A Jul 04 25170:12 wait
root 286 3.1 0.0 40 40 - A Jul 04 25144:00 wait
root 8196 3.0 0.0 40 40 - A Jul 04 25082:32 wait
root 822 3.0 0.0 40 40 - A Jul 04 25072:25 wait
root 554 3.0 0.0 40 40 - A Jul 04 25034:14 wait
root 20776 2.7 0.0 40 40 - A Jul 04 22181:27 wait
root 57372 2.7 0.0 40 40 - A Jul 04 22118:00 wait
root 49176 2.7 0.0 40 40 - A Jul 04 22102:02 wait
root 21044 2.7 0.0 40 40 - A Jul 04 22077:18 wait
root 12848 2.7 0.0 40 40 - A Jul 04 22036:44 wait
root 21312 2.7 0.0 40 40 - A Jul 04 21998:53 wait
root 12580 2.7 0.0 40 40 - A Jul 04 21967:17 wait
root 13116 2.7 0.0 40 40 - A Jul 04 21865:51 wait
oracle 344612 0.3 0.0 56372 33852 - A Jul 04 2707:30 ora_j000_ora92
oracle 430408 0.3 0.0 55916 33396 - A Jul 04 2266:20 ora_j001_ora92
oracle 365092 0.2 0.0 56184 33664 - A Jul 04 1765:58 ora_j002_ora92
oracle 442430 0.2 0.0 56092 33572 - A Jul 04 1426:40 ora_j003_ora92
oracle 385606 0.1 0.0 55984 33464 - A Jul 05 1159:17 ora_j004_ora92
oracle 413856 0.1 0.0 50520 28000 - A Jul 23 543:31 oracleora92 (LOC
oracle 143668 0.1 0.0 50528 28008 - A Jul 13 833:21 oracleora92 (LOC
oracle 369230 0.1 0.0 56600 34080 - A Jul 05 806:36 ora_j005_ora92在这个输出结果中，排在前面的是16个root用户的wait进程，这其实是CPU空闲的时候运行的空闲进程，之前已作说明。
所以CPU最高的几个进程其实是下面的ORACLE用户的ora_j00*进程，这是ORACLE 的job进程。在这里，这些进程的开销很小。如果ORACLE的进程开销比较大，我们可以用如下的方法来查询具体的进程在干什么事情，例如我们要查询进程ora_j000_ora92，
PID=344612，可以使用下面的方法：
$su – oracle
SQL>sqlplus “/as sysdba”
SQL>oradebug setospid 344612
SQL>oradebug event 10046 trace name context forever, level 8
SQL>oradebug tracefile_name –这个命令我们获得输出文件的绝对路径和文件名
SQL>oradebug event 10046 trace name context off
$tkprof /opt/oracle/app/oracle/admin/ora92/bdump/ora92_j000_344612.trc tracepid.txt
$more tracepid.txt
在tracepid.txt中，我们就可以看到这个进程中具体运行的语句、过程等，以及所有的SQL 的cpu消耗、物理读、逻辑读、执行计划等信息。
另外，我们也可以执行下面的语句查看进程具体运行的SQL语句的文本：
SELECT /*+ ORDERED */ sql_text FROM v$sqltext a
WHERE (a.hash_value, a.address) IN (
SELECT DECODE (sql_hash_value,0, prev_hash_value,sql_hash_value), DECODE (sql_hash_value,0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.paddr = (SELECT addr
FROM v$process c
WHERE c.spid = '&pid'))
ORDER BY piece ASC
6、解决CPU占用的惩罚机制nice和renice
指定和修改命令的优先级。
系统中运行的每个进程都有一个优先级，我们可以用ps命令看到，这个优先级为PRI，PRI 的值越小，优先级越高，能占用更多的CPU时间片。系统默认的PRI为60，我们可以通过nice 命令和renice命令来改变一个进程的优先级，从而控制进程对CPU时间片的占用。
任何一个用户都可以使用nice命令来使他的进程以低于系统默认的pri运行。但是只有root用户才可以使进程以高于默认的pri运行。
我们先来看一下nice命令的使用方法：
#nice –n -5 vmstat 2 10 >vmstat.out
# ps -el
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
200001 A 0 704738 1523728 0 55 15 aee1400 544 f100009e63c23e30 pts/1 0:00 vmstat
指定程序以nice值-5开始运行。程序开始后，nice的值为15，PRI的值为55。
nice命令可以指定的范围为-20 (最高优先级)到20 (最低优先级)。在AIX5.3中，默认的nice为20。
# vmstat 2 10 >vmstat.out
# ps -el
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
200001 A 0 704740 1523728 0 60 20 32ec6400 472 f100009e63c23e30 pts/1 0:00 vmstat64
可以看到默认的情况下，系统使用的nice=20，pri=60 。
实际上，在使用nice指定的时候，我们也可以使用超出闭区间[-20,20]的值，比如：
nice –n -33 vmstat 2 10 >vmstat.out
# ps -el
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
200001 A 0 319652 1523728 0 40 0 82ef0400 544 f100009e63c23e30 pts/1 0:00 vmstat64
上例中，我们指定的nice小于-20，得到最高的优先级（pri=40）。反之，如果我们指定nice 的值超过20，比如nice=21，我们将得到最低的优先级值pri=100。
renice不能在具有固定优先级的进程上使用。非root用户可以在一个或多个运行进程的nice值上加一个指定的值，但不能从中减去指定的值。也就是只能降低进程的优先级，而不能增加优先级。
renice -n -10 pidnumber ，将指定的进程nice值减小10。
renice -n +5 pidnumber ，将指定的进程nice值增加5。
根据nice值的不同取值，这里renice的值可以取值的范围是闭区间[-40,40 ]。为什么取值范围是这个呢？我们可以这样来理解，通过ps –l命令，我们可以看到NI的取值范围是闭区间[0,40]，我们使用renice需要改变的也就是整个值，考虑两个极端的情况，假如现在为0，我们要把它改到40，就必须得renice –n 40，如果现在是40，我们要把它改为0，则renice 的值就得是-40了。
当然，跟nice一样，在这里renice的值在命中使用的时候也可以超出这个闭区间，不会报错，但有效的结果只落在这个闭区间内。
# ps l 1630282
FSUID PID PPID C PRI NI ADDR SZ RSS WCHAN TTY TIME CMD
200001 A 0 1630282 680062 0 100 40 413e8400 472 484 EVENT pts/1 0:00 v
# renice -n -30 1630282
# ps l 1630282
FSUID PID PPID C PRI NI ADDR SZ RSS WCHAN TTY TIME CMD
200001 A 0 1630282 680062 0 50 10 413e8400 472 484 EVENT pts/1 0:00 v
我们可以总结一下，pri值的取值公式大概如下：
优先级值（PRI）= 基本优先级（60）＋nice损失＋基于最近CPU使用情况的CPU损失
总的来说nice值越小，进程的优先级越高，能分配到更多的cpu时间片。反之，也成立。7、小结
对于系统cpu的监控，建议：
1）使用vmstat进行分析
2）sar –P ALL 1 10 分析，多个cpu间的负载是否平衡
3）ps aux 查看
4）tprof查看更详细的信息
对于AIX主机的性能评估，我们从下面的4个方面来逐一介绍：CPU、MEMORY、I/O系统和网络这4个方面来描述。
二、Memory性能评估
1、VMM的管理简介
首先，还是简单讲解一下内存以及的VMM的一点工作原理。
内存和交换空间一般都是用页面来进行分配和管理的。在内存中存在两种类型的页面：计算页面（一般为可执行文件段中的页面）和文件页面（存储的数据文件的页面）。当我们执行程序或者读入数据的时候，内存中的页面就逐渐被占用。当空闲的内存只剩maxfree的时候，vmm 的调页就被唤醒，通过调页算法，将内存中的页面转移到交换空间中。一直到空闲内存达到maxfree，才停止调页。
在这里，我们涉及到两个参数：
1)Minfree：最小空闲页链表尺寸。一旦低于该值，系统偷页以填充页链表，保证有足够的内存
页面。偷页就是将不常用的页面替换出去。
2)Maxfree：最大空闲页链表尺寸。一旦高于该值，系统停止偷页。
https://www.wendangku.net/doc/a916628933.html,
如果发现空闲列表不足，可以用下面的方法增加minfree参数
#vmo -o minfree=1000 -o maxfree=1008
Setting maxfree to 1008
Setting minfree to 1000
#vmo –o minfree=1000 –o maxfree=1008 –P # -P参数使修改永久生效
一般情况下，minfree和maxfree通过下面的公式得到：
maxfree=minmum(memory/128,128) ,minfree=maxfree-8
注意：在AIX 5.2之前的版本请使用/usr/samples/kernel/vmtune命令。
#/usr/samples/kernel/vmtune –f 1000 –F 1008
另外，关于内存的使用，我们还有两个经常碰到的参数需要关注：
Minperm：用户I/O文件访问的最小缓冲区页数
Maxperm：用户I/O文件访问的最大缓冲区页数
Minperm和maxperm这两个参数的默认值分别为20％和80％。在这里主要与性能相关的是maxperm参数。maxperm参数指定了文件页面可以占用内存的上限，因为文件页面
不主动释放，所以很容易造成内存的文件页面过高的占用，导致其他的应用内存使用紧张。调整参数值的方法如下：
#vmo -o maxperm%=80 -o minperm%=20
Setting minperm% to 20
Setting maxperm% to 80
在AIX 5.2之前的版本请使用/usr/samples/kernel/vmtune命令。
#/usr/samples/kernel/vmtune -p 20–P 80 将min和max的值分别设置为20％和80％。
查看当前的参数设置方法如下：
1）vmo –a 显示当前所有的参数设置
在AIX 5.2之前的版本请使用# /usr/samples/kernel/vmtune 显示当前所有的参数设置#vmo -a
cpu_scale_memp = 8
data_stagger_interval = 161
defps = 1
force_relalias_lite = 0
framesets = 2
htabscale = n/a
kernel_heap_psize = 4096
large_page_heap_size = 0
lgpg_regions = 0
lgpg_size = 0
low_ps_handling = 1
lru_file_repage = 1
lru_poll_interval = 10
lrubucket = 131072
maxclient% = 80
maxfree = 1088
maxperm = 4587812
maxperm% = 80
maxpin = 4881650
maxpin% = 80
mbuf_heap_psize = 4096
memory_affinity = 1
memory_frames = 6029312
memplace_data = 2
memplace_mapped_file = 2
memplace_shm_anonymous = 2
memplace_shm_named = 2
memplace_stack = 2
memplace_text = 2
memplace_unmapped_file = 2
mempools = 4
https://www.wendangku.net/doc/a916628933.html,技术社区
minfree = 960
minperm = 1146952 minperm% = 20
nokilluid = 0
npskill = 49152
npsrpgmax = 393216 npsrpgmin = 294912 npsscrubmax = 393216 npsscrubmin = 294912 npswarn = 196608
num_spec_dataseg = 0 numpsblks = 6291456
page_steal_method = 0 pagecoloring = n/a pinnable_frames = 5601758 pta_balance_threshold = n/a relalias_percentage = 0 rpgclean = 0
rpgcontrol = 2
scrub = 0
scrubclean = 0
soft_min_lgpgs_vmpool = 0 spec_dataseg_int = 512 strict_maxclient = 1
strict_maxperm = 0
v_pinshm = 0
vm_modlist_threshold = -1 vmm_fork_policy = 1
vmm_mpsize_support = 1 2）vmstat -v
# vmstat -v
6029312 memory pages 5734766 lruable pages 2801540 free pages
4 memory pools
406918 pinned pages
80.0 maxpin percentage 20.0 minperm percentage 80.0 maxperm percentage 2.3 numperm percentage https://www.wendangku.net/doc/a916628933.html,社区论坛135417 file pages
0.0 compressed percentage 0 compressed pages
0.0 numclient percentage
80.0 maxclient percentage
0 client pages
0 remote pageouts scheduled
312417 pending disk I/Os blocked with no pbuf
0 paging space I/Os blocked with no psbuf
2878 filesystem I/Os blocked with no fsbuf
0 client filesystem I/Os blocked with no fsbuf
0 external pager filesystem I/Os blocked with no fsbuf
显示minperm和maxperm和numperm的值。numperm值给出的是内存中文件页数。
系统调页的规则：
1)如果numperm>maxperm，则只调出文件页面。
2)如果numperm 3)如果minperm 大于计算页面的总和。 如果系统在向调页空间调出页面，可能使因为内存中的文件页数低于maxperm，从而也调出了部分的计算页面以达到maxfree的要求。在这种情况下，可以考虑把maxperm降低到低于numperm的某个值，从而阻止计算页面的调出。在5.2 ML4以后的版本中，为了防止计算页面被调出，可以采用另外一个方法，就是设置参数lru_file_repage=0。将该参数设为0，则告诉vmm在进行页面替换的时候，优先替换文件页面。 maxclient通常应该设置为一个小于或者等于maxperm的值。 增强JFS文件系统为它的缓冲区高速缓存使用客户机文件，这不受maxperm和minperm的影响。为了在限制增强JFS文件系统使用高速缓存，可以指定maxclient的值，避免在它进行页面替换的时候，替换其他类型的页。 https://www.wendangku.net/doc/a916628933.html,社区论坛 2、使用vmstat确定内存的使用情况 主要检查vmstat输出的memory和pages列和faults列。详细的说明见前一节cpu评估说明。 3、svmon命令 # svmon -G -i 2 2 size inuse free pin virtual memory 2097136 236845 1860291 152150 194943 pg space 1048576 960 work pers clnt lpage pin 151904 246 0 0 in use 194960 41885 0 0 size inuse free pin virtual memory 2097136 236853 1860283 152150 194947 pg space 1048576 960 work pers clnt lpage pin 151904 246 0 0 in use 194964 41889 0 0 memory段 ?size 物理内存总页数。4KB/页 ?inuse 物理内存中正在使用的内存页面数。包含活动进程和已经终止的进程的持久文件页面。 ?free 空闲列表中的页面数量 ?pin 锁定在内存中的页面数量（锁定的意思就是不能被替换出去） ?virtual pg space段 https://www.wendangku.net/doc/a916628933.html, ?size 调页空间总大小 ?inuse 已经分配页的总数，也就是已经使用的调页空间页数 pin段 ?work 物理内存中的工作页面数 ?pers 物理内存中的持久页面数 ?clnt 物理内存中的客户机页面数（客户机页面就是一个远程文件页面） inuse段 ?work 物理内存中的工作页面数 ?pers 物理内存中的持久页面数 ?clnt 物理内存中的客户机页面数（客户机页面就是一个远程文件页面） 3、ps命令显示当前运行的进程状态信息。 运行下列命令，显示内存占用前10位的进程。 # ps gv |sort +6b -nr |head -10 2490538 - A 191:56 0 11840 32748 xx 45762 20924 0.1 0.0 ora_j00 2039970 - A 592:59 11 11728 32648 xx 45762 20924 0.3 0.0 ora_j00 2588922 - A 1118:31 22 11712 32632 xx 45762 20924 0.6 0.0 ora_j0 2523168 - A 305:01 1 11688 32608 xx 45762 20924 0.2 0.0 ora_j00 2474214 - A 0:01 0 11588 32512 xx 45762 20924 0.1 0.0 ora_j00 2007282 - A 0:01 0 10384 31308 xx 45762 20924 0.0 0.0 ora_j00 508120 - A 32:58 662 9344 27164 xx 45762 20924 0.0 0.0 ora_dbw 1351908 - A 0:02 1 5668 26560 xx 45762 20924 0.0 0.0 oracleo 3801250 - A 203:22 0 5648 26556 xx 45762 20924 0.1 0.0 oracleo 4、内存的调整 具体调整需要结合系统运行的应用程序对症下药，如调整minperm/maxperm将改变内存与PAGING SPACE之间的交换算法，调整minpgahead/maxpgahead将改变内存块请求机制，调整minfree/maxfree将改变内存紧张时的内存清理刷新机制，等等。如果数据库使用裸设备，并且没有太多其他的应用，因为裸设备不需要文件系统的缓存，所以可以降低minperm，maxperm，maxclient的默认值，降低操作系统对内存的不必要的占用。 案例： 计费数据库数据库响应变慢，内存16G，裸设备，却存在很多的PI,PO情况。 https://www.wendangku.net/doc/a916628933.html, 在检查与内存相关的系统参数，发现如下问题： minperm% = 20，maxperm% = 80，maxclient% = 80 说明：以上三个参数为系统缺省配置，其表示，使用文件系统时，最多可使用80% * 16G=10.8G，用于缓存所访问的文件。 结论：由于以上参数采用系统缺省配置，文件系统缓存最大可以达到10.8G,在执行大量的文件cp操作后，系统的可用内存量迅速下降，在其后的计费过程中，由于大量page in/page out 操作引起系统严重性能瓶颈。 优化： 将maxperm% = 30 ，maxclient% = 30 #vmo –o maxperm%=30 –P #vmo –o maxclient%=30 –P 5.2以前版本 /usr/samples/kernel/vmtune –p 20 –P 30 /usr/samples/kernel/vmtune –t 30 三、磁盘的I/O性能评估 对磁盘IO的性能考虑： 1)将频繁访问的文件系统和裸设备应尽可能放置在不同的磁盘上。 2)在建立逻辑卷时尽可能使用mklv的命令开关给不同的文件系统和裸设备赋予不同的内策略。 3)使用磁盘设备驱动适配器的功能属性构建合适的RAID方式,以获得更高的数据安全性和存取 性能。一般考虑采用RAID5或者RAID10方式，对于写要求比较高的系统，一般建议采用RAID10方式;关于RAID10 与RAID 5的比较，可以见piner的文章，作为补充我会在后面贴出。 4)尽可能利用内存读写带宽远比直接磁盘I/O操作性能优越的特点,使频繁访问的文件或数据 置于内存中进行操作处理; https://www.wendangku.net/doc/a916628933.html,社区论坛 在这里，顺带提一下裸设备以及文件系统的对比。 裸设备的优点： 1)由于旁路了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意 味着取消了硬盘与文件系统的同步需求。这一点对于纯OLTP系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。除了OLTP，raw设备还能够从以下几个方面改善DSS应用程序的性能： 排序：对于DSS环境中大量存在的排序需求，raw设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。 序列化访问：raw设备非常适合于序列化I/O动作。同样地，DSS中常见的序列化I/O（表/索引的完全扫描）使得raw设备更加适用于这种应用程序。 2)直接读写，不需要经过OS级的缓存。节约了内存资源，在一定程度上避免了内存的争用。 3)避免了操作系统的cache预读功能，减少了I/O。 4)采用裸设备避免了文件系统的开销。比如维护I-node，空闲块等。 裸设备的缺点： 1、裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。 2、很多备份工具软件对裸设备的支持不足，导致备份等的操作和方法比较原始、麻烦。 接下来，对于磁盘I/O的性能性能评估的方法。 1、iostat查看 #iostat 1 3 System configuration: lcpu=16 drives=11 paths=4 vdisks=0 tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 59.7 30.4 17.0 25.6 27.1 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 1.0 4.0 1.0 0 4 hdisk0 0.0 4.0 四、NETWORK性能评估 网络的性能可以通过以下一些方法进行监控和优化： 1、ping命令查看网络的连通性 如果一旦发现网络发现问题，我们最常规的使用方法就是使用ping命令来检查网络的连通情况。# ping 10.33.102.107 PING 10.33.102.107: (10.33.102.107): 56 data bytes 64 bytes from 10.33.102.107: icmp_seq=0 ttl=255 time=4 ms 64 bytes from 10.33.102.107: icmp_seq=1 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=2 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=3 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=4 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=5 ttl=255 time=0 ms https://www.wendangku.net/doc/a916628933.html,社区论坛 64 bytes from 10.33.102.107: icmp_seq=6 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=7 ttl=255 time=0 ms ^C ----10.33.102.107 PING Statistics---- 8 packets transmitted, 8 packets received, 0% packet loss 上面的结果中，最后一行是一个总结，0% packet loss可以检查网络的质量，丢包率。从time=0 ms，我们也可以来判断这两台主机之间网络传送的延时情况。 2、netstat –i检查网络的接口 这个命令可以用来检查网络的接口情况。 #netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en0 1500 link#2 0.d.60.b.98.e2 5022475 0 4643590 0 0 en0 1500 10.33.102.9 oracle1_boot 5022475 0 4643590 0 0 en2 1500 link#3 0.d.60.b.96.78 4925323 0 4515364 0 0 en2 1500 192.100.10 oracle1_stb 4925323 0 4515364 0 0 en3 1500 link#4 0.2.55.cf.4d.b9 0 0 7 0 0 en3 1500 10.0.2 oracle1 0 0 7 0 0 lo0 16896 link#1 4789337 0 4791656 0 0 lo0 16896 127 loopback 4789337 0 4791656 0 0 lo0 16896 ::1 4789337 0 4791656 0 0 对于上述的输出结果，说明如下： ?name 接口名称 ?Mtu 最大传输单元，单位字节 ?Ipkts 接收到的信息包总数量 ?Ierrs 接收失败的包总数，比如，畸形的信息包、校验和错误或是设备驱动程序中的缓冲空间不足。 ?Opkts 发送的信息包总数量 https://www.wendangku.net/doc/a916628933.html,社区论坛 ?Oerrs 发送失败的包总数，比如，主机连接错误或者适配器输出队列超限。 ?Coll 检测到包冲突的次数 如果Ierrs/ Ipkts超过1％，就需要通过netstat –m来检查存储器的内存使用情况。 如果Oerrs/ Opkts超过1％，就需要为这个接口增加发送队列的大小（xmt_que_size），xmt_que_size的值可以通过下面的命令来检查： #lsattr –El adapter 如果Coll/Opkts超过10％，则网络的使用率比较高，有必要重新组合或是分区，使用netstat –v或者enstat 命令可以确定冲突的比率。 3、netstat –r检查主机的路由情况 Netstat –r可以用来检查主机的路由情况。在这里，default表示的是默认路由。在很多网络不通的时候，我们可以首先检查路由表的情况，如果路由表不存在太多的问题，可以再使用traceroute命令来检查包的传送路径，从而定位网络问题。 #netstat -r Routing tables Destination Gateway Flags Refs Use If Exp Groups Route Tree for Protocol Family 2 (Internet): default 10.33.102.97 UG 316 597250728 en7 - - 10.33.102.96 jsdxh_db_svc UHSb 0 0 en7 - - => 10.33.102.96/28 jsdxh_db_svc U 195 2288404800 en7 - - jsdxh_db_svc loopback UGHS 0 635942 lo0 - - 10.33.102.111 jsdxh_db_svc UHSb 0 261 en7 - - 127/8 loopback U 44 8771083 lo0 - - 192.168.0.0 jsdxh_db01_stby UHSb 0 0 en9 - - => 192.168.0/28 jsdxh_db01_stby U 2 3781828 en9 - - jsdxh_db01_stby loopback UGHS 0 2463802 lo0 - - 192.168.0.15 jsdxh_db01_stby UHSb 0 272 en9 - - Route Tree for Protocol Family 24 (Internet v6): https://www.wendangku.net/doc/a916628933.html,技术社区 ::1 ::1 UH 0 48 lo0 - - 关于输出结果的一点说明： Destination：表示路由的目的地。Default则表示该条路由位默认路由。在有些系统上，则使用0.0.0.0来表示默认路由。 Gateway：网关 Flag：flag的字段值比较多，不一一说明。这里的U表示up。G表示路由至网关。H表示路由至主机而不是网络。S表示手工添加。b表示该路由为广播地址。 Refs：给出当前活动使用的路由数目。面向连接协议在连接持续时间内保留单独的路由，而无连接协议在发送给同一目标时获取路由。 Use：提供使用该路由发送的信息包数目的计数。 If：表示本路由利用的网络接口。其中lo0表示回环地址。En7表示以太网口7。 Exp：该字段无效。 Group：该字段无效。 下面是给出的一个traceroute示例： # traceroute 10.33.102.107 trying to get source for 10.33.102.107 source should be 10.33.102.105 traceroute to 10.33.102.107 (10.33.102.107) from 10.33.102.105 (10.33.102.105), 30 hops max outgoing MTU = 1500 1 oracle_svc (10.33.102.107) 1 ms 0 ms 0 ms Netstat命令的其他用法，简单介绍。 Netstat –t命令可以用来检查外部链接的情况，在这里可以看到链路所使用协议，以及端口情况。 # netstat -ta |grep –v loopback | more Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.daytime 4、netpmon netpmon命令用于监控与网络有关的I/0及CPU的使用情况。 以root 身份运行下面的命令，可以找出进程使用的CPU时间，以及其中与网络有关的代码使用的CPU时间： # netpmon -o /tmp/netpmon.out -O cpu -v; sleep 30; trcstop 此命令运行30 秒钟，并在/tmp目录下生成文件netpmon.out。其中字段CPU Time 为进程使用CPU 的时间总值，CPU%对应其百分比，Network CPU% 为进程中与网络有关的代码所占用的CPU 百分比。如下所示： TIME: 30.002476450 TRACE OFF # more /tmp/netpmon.out Wed Aug 15 16:15:15 2007 System: AIX oracle2 Node: 5 Machine: 005073CD4C00 trace -a -T 256000 -o - -j 000,000,001,002,003,005,006,106,10C,139,134,135,100,200,102,103,101,104, 465,467,46A, 00A,256,255,262,26A,26B,32D,32E,2A7,2A8,351,352,320,321,30A,30B,330,331, 334,335,2C3,2C4,2A4,2A5,2E6,2E7,2DA,2DB ,2EA,2EB,252,216,211 TIME: 0.000000000 TRACE ON pid 1662992 tid 0x2a8015 TIME: 30.002476450 TRACE OFF Hook counts ----------------------------- TrcOn: 1 TrcOff: 1 5、其他一些常用的命令 Arp Route Ifconfig Nslookup等等。 这些命令，在这里不再一一介绍，有兴趣的可以查看相关资料。 ?论著?７６００生化分析仪检测系统的性能验证 马红雨 熊雪松 罗丹 安映红 【摘要】 目的 对日本Ｈｉｔａｃｈｉ公司７６００型全自动生化分析仪检测系统主要分析性能进行验 证。方法 参照美国临床实验室标准化委员（ＮＣＣＬＳ）指南有关检测系统性能验证文件ＥＰ５唱Ａ、ＥＰ６唱 Ａ的方法对选定生化检测项目的精密度、线性、可报告范围进行评价。结果 日立７６００检测各项目 批内精密度结果除Ｎａ外，均在１／４ＣＬＩＡ′８８要求的范围内，批间精密度结果除Ｎａ外均在１／３ＣＬＩＡ′８８ 要求的范围内；线性验证标本按一定比例稀释后得到理论值与实测值的回归方程ｙ＝ｂｘ＋ａ中，ｂ均在 ０畅９７～１畅０３范围内，ａ在可接受范围内；可报告范围验证结果显示，标本经不同比例稀释后，理论值／ 实测值均在９０％～１１０％，说明在一定范围内的标本稀释检测结果可靠。结论 该检测系统的精密 度、线性、可报告范围三个方面基本符合临床实验诊断学实验的要求，Ｎａ的检测方法需要改进。 【关键词】 全自动生化仪； 检测系统； 性能验证 Ｐｅｒｆｏｒｍａｎｃｅｖｅｒｉｆｉｃａｔｉｏｎｏｆｔｈｅ７６００ｂｉｏｃｈｅｍｉｃａｌａｎａｌｙｚｅｒｄｅｔｅｃｔｉｏｎｓｙｓｔｅｍ ＭＡＨｏｎｇ唱ｙｕ，ＸＩＯＮＧＸｕｅ唱 ｓｏｎｇ，ＬＵＯＤａｎ，ＡＮＹｉｎｇ唱ｈｏｎｇ．ＣｌｉｎｉｃａｌＬａｂｏｒａｔｏｒｙＣｅｎｔｅｒ，ＧｅｎｅｒａｌＨｏｓｐｉｔａｌｏｆＡｉｒＦｏｒｃｅ，Ｂｅｉｊｉｎｇ １００１４２，Ｃｈｉｎａ Ｃｏｒｒｅｓｐｏｎｄｉｎｇａｕｔｈｏｒ：ＭＡＨｏｎｇ唱ｙｕ，Ｅｍａｉｌ：ｍｈｙ０６０５２＠１６３．ｃｏｍ 【Ａｂｓｔｒａｃｔ】 Ｏｂｊｅｃｔｉｖｅ Ｔｏｖｅｒｉｆｙｔｈｅｍａｉｎａｎａｌｙｚｉｎｇｐｅｒｆｏｒｍａｎｃｅｏｆｔｈｅ７６００ａｕｔｏｍａｔｉｃｂｉｏｃｈｅｍｉｃａｌ ａｎａｌｙｚｅｒ，ｐｒｏｄｕｃｔｉｏｎｏｆＨｉｔａｃｈｉＣｏｒｐｏｒａｔｉｏｎｏｆＪａｐａｎ．Ｍｅｔｈｏｄｓ ＦｏｌｌｏｗｉｎｇｔｈｅｍｅｔｈｏｄｈｏｗＥＰ５唱Ａ，ＥＰ６唱Ａ ｗｅｒｅｔｅｓｔｅｄａｓｄｅｓｃｒｉｂｅｄｉｎｔｈｅｉｎｓｔｒｕｃｔｉｏｎｏｆｔｈｅＮａｔｉｏｎａｌＣｏｍｍｉｔｔｅｅｆｏｒＣｌｉｎｉｃａｌＬａｂｏｒａｔｏｒｙＳｔａｎｄａｒｄｓ （ＮＣＣＬＳ），ｐｒｅｃｉｓｉｏｎ，ｌｉｎｅａｒｉｔｙａｎｄｒｅｐｏｒｔａｂｌｅｒａｎｇｅｏｆｔｈｅｓｅｌｅｃｔｅｄｂｉｏｃｈｅｍｉｃａｌｔｅｓｔｉｎｇｉｔｅｍｓｗｅｒｅｅｖａｌｕａｔｅｄ． Ｒｅｓｕｌｔｓ Ａｌｌｔｈｅｗｉｔｈｉｎ唱ｒｕｎｐｒｅｃｉｓｉｏｎｏｆＨｉｔａｃｈｉ７６００ｔｅｓｔｉｎｇｉｔｅｍｓｗｅｒｅｗｉｔｈｉｎｔｈｅｒｅｑｕｉｒｅｄ１／４ＣＬＩＡ′８８ ｂｕｔＮａ，ａｌｌｔｈｅｂｅｔｗｅｅｎ唱ｒｕｎｐｒｅｃｉｓｉｏｎｗｅｒｅｗｉｔｈｉｎｔｈｅｒｅｑｕｉｒｅｄ１／３ＣＬＩＡ′８８ｂｕｔＮａ；ｔｈｅｌｉｎｅａｒｖｅｒｉｆｉｃａｔｉｏｎ ｒｅｓｕｌｔｓｇｏｔｔｈｅｒｅｇｒｅｓｓｉｏｎｅｑｕａｔｉｏｎｏｆｔｈｅｔｈｅｏｒｅｔｉｃａｌａｎｄｍｅａｓｕｒｅｄｖａｌｕｅｓｙ＝ｂｘ＋ａ，ｉｎｗｈｉｃｈｂｗａｓｗｉｔｈｉｎｔｈｅ ｒａｎｇｅｏｆ０畅９７唱１畅０３，ａｗａｓｗｉｔｈｉｎａｎａｃｃｅｐｔａｂｌｅｒａｎｇｅ；ｔｈｅｒｅｐｏｒｔａｂｌｅｒａｎｇｅｖｅｒｉｆｉｃａｔｉｏｎｒｅｓｕｌｔｓｓｈｏｗｅｄｔｈａｔ ａｆｔｅｒｔｈｅｓａｍｐｌｅｓｂｅｉｎｇｄｉｌｕｔｅｄｂｙｄｉｆｆｅｒｅｎｔｐｒｏｐｏｒｔｉｏｎｓ，ｔｈｅｔｈｅｏｒｅｔｉｃａｌ／ｍｅａｓｕｒｅｄｖａｌｕｅｓｗｅｒｅａｌｌｂｅｔｗｅｅｎ ９０％ａｎｄ１１０％，ｉｎｄｉｃａｔｉｎｇｔｈａｔｗｉｔｈｉｎａｃｅｒｔａｉｎｒａｎｇｅｏｆｓａｍｐｌｅｄｉｌｕｔｉｏｎｔｈｅｔｅｓｔｒｅｓｕｌｔｓｗｅｒｅｒｅｌｉａｂｌｅ． Ｃｏｎｃｌｕｓｉｏｎｓ Ｐｒｅｃｉｓｉｏｎ，ｌｉｎｅａｒｉｔｙａｎｄｒｅｐｏｒｔａｂｌｅｒａｎｇｅｏｆｔｈｅｄｅｔｅｃｔｉｏｎｓｙｓｔｅｍｍｅｔｔｈｅｂａｓｉｃｒｅｑｕｉｒｅｍｅｎｔｓｏｆ ｔｈｅｅｘｐｅｒｉｍｅｎｔｓｉｎｃｌｉｎｉｃａｌｄｉａｇｎｏｓｉｓａｎｄｔｈｅｍｅｔｈｏｄｄｅｔｅｃｔｉｎｇＮａｓｈｏｕｌｄｂｅｉｍｐｒｏｖｅｄ． 【Ｋｅｙｗｏｒｄｓ】 Ａｕｔｏｍａｔｉｃｂｉｏｃｈｅｍｉｃａｌａｎａｌｙｚｅｒ； Ｄｅｔｅｃｔｉｏｎｓｙｓｔｅｍ； Ｐｅｒｆｏｒｍａｎｃｅｖｅｒｉｆｉｃａｔｉｏｎ 检测系统是指检测某些项目所涉及的仪器、试剂、校准品等的组合。为了保证检验结果的准确性，为临床疾病诊断、治疗提供可靠依据，卫生部枟医疗机构临床实验室管理办法枠［１］和ＩＳＯ１５１８９［２］要求应对非配套检测系统进行性能验证，以证实该检测系统能够达到厂家的承诺和临床的要求。本文参照美国临床实验室标准化委员（ＮＣＣＬＳ）指南文件的要求对生化７６００全自动生化分析仪的部分检测项目精密度、线性、可报告范围进行了系统评价，希望检验同行有所借鉴并提出宝贵意见。 ＤＯＩ：１０．３８７７／ｃｍａ．ｊ．ｉｓｓｎ．１６７４唱０７８５．２０１１．０９．０２７ 作者单位：１００１４２ 北京，空军总医院临床检验中心（马红雨、罗丹、安映红）；大连医学院检验系（熊雪松） 通讯作者：马红雨，Ｅｍａｉｌ：ｍｈｙ０６０５２＠１６３．ｃｏｍ 言简意赅，远见卓识。望君采纳。谢谢！删除水印可，编辑页眉，选中水印，点击删除。 软件系统测试报告 实用版 2019年06月 版本修订记录 测试报告 目录 1引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3术语解释 (1) 1.4参考资料 (1) 2测试概要 (2) 2.1系统简介 (2) 2.2测试计划描述 (2) 2.3测试环境 (2) 3测试结果及分析 (3) 3.1测试执行情况 (3) 3.2功能测试报告 (3) 3.2.1系统管理模块测试报告单 (3) 3.2.2功能插件模块测试报告单 (4) 3.2.3网站管理模块测试报告单 (4) 3.2.4内容管理模块测试报告单 (4) 3.2.5辅助工具模块测试报告单 (4) 3.3系统性能测试报告 (4) 3.4不间断运行测试报告 (5) 3.5易用性测试报告 (5) 3.6安全性测试报告 (6) 3.7可靠性测试报告 (6) 3.8可维护性测试报告 (7) 4测试结论与建议 (9) 4.1测试人员对需求的理解 (9) 4.2测试准备和测试执行过程 (9) 4.3测试结果分析 (9) 4.4建议 (9) 1引言 1.1 编写目的 本测试报告为xxxxxx软件项目的系统测试报告，目的在于对系统开发和实施后的的结果进行测试以及测试结果分析，发现系统中存在的问题，描述系统是否符合项目需求说明书中规定的功能和性能要求。 预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。 1.2 项目背景 ?项目名称：xxxxxxx系统 ?开发方：xxxxxxxxxx公司 1.3 术语解释 系统测试：按照需求规格说明对系统整体功能进行的测试。 功能测试：测试软件各个功能模块是否正确，逻辑是否正确。 系统测试分析：对测试的结果进行分析，形成报告，便于交流和保存。 1.4 参考资料 1)GB/T 8566—2001 《信息技术软件生存期过程》(原计算机软件开发规范) 2)GB/T 8567—1988 《计算机软件产品开发文件编制指南》 3)GB/T 11457—1995 《软件工程术语》 4)GB/T 12504—1990 《计算机软件质量保证计划规范》 5)GB/T 12505—1990 《计算机软件配置管理计划规范》 5.4.2测试结果分析 LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图5- 1所示。性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。我们回顾一下本次性能测试的目的，正如错误！未找到引用源。所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU 使用率、内存使用率分别不超过75%、70%，那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。 图5- 1性能测试结果分析流程图 结果摘要 LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图5- 2所示。概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。以简要的信息列出本次测试结果。 图5- 2性能测试结果摘要图 场景执行情况 该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 3所示。从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。与我们场景执行计划中设计的时间基本吻合。 图5- 3场景执行情况描述图 Statistics Summary（统计信息摘要） 该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 4所示。从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。 图5- 4统计信息摘要图 Transaction Summary（事务摘要） 该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图5- 5所示。从该图我们得到每个Action的平均响应时间与业务成功率。 雅培ARCHEITECT C800全自动生化分析仪检测系统性能验证 发表时间：2017-05-31T16:30:05.460Z 来源：《心理医生》2017年11期作者：费海霞陈文英马玉翠陈忠祥王向华 [导读] 为保证临床实验室检验结果的准确和可靠，根据实验室的有关要求，应对非配套检验系统的精密度。 （江苏省昆山市第六人民医院检验科江苏昆山 15321） 【摘要】目的：对雅培ARCHEITECT C800全自动生化分析仪（简称雅培 C800）的肾功能三项，即尿素氮（BUN）、肌酐（CREN）、尿酸（UA）的精密度（批内、日间）、正确度、线性范围以及生物参考区间等相关分析性能进行评价。方法：根据美国临床实验室标准化研究所（CLSI)文件（EP5-A2、EP15-A2)以及中华人民共和国卫生行业标准（简称卫生行业标准）的相关文件进行评价。结果：BUN、CREN及UA的中、高值的批内精密度均小于1/4总误差（TEa），日间精密度均小于1/3总误差（TEa）；BUN、CREN及UA的各项目线性良好，线性回归方程的斜率均在1.00±0.03范围内，R2均≥0.95，线性范围分别为0～38.83mmol/L、0～1289umol/L、0～884.5umol/L；对江苏省2015年第二次5份室间质控物的BUN、CREN、UA检测结果与靶值的偏倚分别为-2.30％～0.61％、-2.74％～0.79％、0.38％～2.86％之间，均小于1/2总误差；各项目的生物参考区间验证结果均在本实验室引用的参考区间内。结论：雅培ARCHEITECT C800全自动生化分析仪对BUN、CREN、UA检测的主要性能符合质量目标要求，能够满足各个层次医院的临床检测需要。 【关键词】雅培 C800全自动生化分析仪；性能验证；精密度；正确度 【中图分类号】R197.38 【文献标识码】A 【文章编号】1007-8231（2017）11-0277-02 为保证临床实验室检验结果的准确和可靠，根据实验室的有关要求，应对非配套检验系统的精密度、正确度、可报告范围等进行评价，本文参照中华人民共和国卫生行业标准（WS/T 403-2012、WS/T 408-2012、WS/T 404.5-2015），对雅培C800全自动分析仪检测的BUN、CREN及UA三项进行分析验证，现报道如下： 1.材料与方法 1.1 材料 1.1.1仪器雅培ARCHEITECT C800全自动生化分析仪。 1.1.2试剂和校准品尿素氮（BUN）、肌酐（CREN）、尿酸（UA）测定试剂盒（批号分别为412193L、502111B、411293K）；校准品(批号分别为：510212C、502111K、501131A)，均由北京利德曼生化股份有限公司提供。 1.1.3质控品中值质控品（批号26401）、高值质控品(批号26402），均由伯乐生命医疗产品（上海）有限公司提供。 1.1.4雅培 C800全自动生化分析仪所使用的试剂、校准品及质控品均在有效期内。 1.1.5样本来源所用样本均采自我院正常体检人群或就诊患者，样本要求为新鲜血清（无溶血、无黄疸、无脂血）；样本采集严格按照《临床化学检验血液标本的收集与处理》（WS/T 225-2002）[1]要求进行。 1.2 方法 1.2.1质控检测选用26401、26402两个浓度质控品，每天进行室内质量控制，所检测的指标在控状态下对精密度、线性范围、正确度以及生物参考区间进行评价。 1.2.2批内精密度参考美国临床实验室标准化研究所（CLSI)EP5-A2[2]文件，使用伯乐的26401、26402两个浓度质控品，每个浓度的质控品连续测定20次，统计20次的检测均值(x-)和标准差(s)，计算变异系数(CV)，判定标准为小于1/4总误差（TEa）。 1.2.3日间精密度参考CLSI EP5-A2[2]文件，每天检测伯乐的26401、26402两个浓度的质控品1次，连续检测20天，剔除失控数据(失控结果已得到纠正)后，统计20天的检测均值(x-)和标准差(s)，计算变异系数(CV)，判定标准为小于1/3总误差（TEa）。 1.2.4正确度参考CLSI EP15-A2[3]文件，使用2015年江苏省临检中心第2次室间质评回报数据进行分析(批号：201521、201522、201523、201524、201525；室间质评的成绩均满足质量目标要求)，计算每份样本检测结果与靶值的偏倚，判定标准为小于1/2总误差（TEa）。 1.2.5线性范围参考卫生行业标准（WS/T408-2012）《临床化学设备线性评价指南》[4]，选取新鲜高值（H)血清样本和生理盐水（L)各一份，将H和L按5L、1H+4L、2H+3L、3H+2L、4H+1L、5H配制成6个浓度样本，每样本按照从低浓度到高浓度顺序测定3次，再按照从高浓度到低浓度顺序测定3次，计算均值，以Ｘ表示各样本的预期值，以Ｙ表示各样本的实测均值，得直线回归Ｙ=aＸ+b,得到a、b及R2值。a为斜率，b为Ｙ轴截距，R2为相关系数的平方，判断其是否呈线性。 1.2.6生物参考区间挑选本院健康成人（20～79岁）体检者40例，男女各半，对引用参考范围进行验证，只允许10%的数据超过所验证的参考范围，否则需建立新的参考范围。判定标准R=（测定结果在参考范围的例数/总测定例数）×100,结果≥90%为合格。 2.讨论 临床检验结果的质量直接关系到患者的诊断、治疗和预后，随着医学的发展，全自动生化仪的广泛使用，极大提高了工作效率。我们依据相关文件和卫生行业标准，探讨并制定了雅培ARCHEITECT C800全自动生化分析仪对BUN、CREN、UA各个项目的性能验证方案，并对该检测系统进行了评价，验证主要包括精密度(批内、日间)、正确度、线性范围以及生物参考区间。 其中，检测系统BUN、CREN、UA各项目的批内精密度均小于1/4总误差（TEa），日间精密度均小于1/3总误差（TEa），符合卫生行业标准，可认为该仪器测定的各个项目的精密度验证通过；再确认检测系统精密度符合要求的基础上，进行正确度验证，结果显示，BUN、CREN、UA的正确度分别在-2.30％～0.61％、-2.74％～0.79％、0.38％～2.86％之间，均小于1/2总误差（TEa），可认为该仪器测定BUN、CREN、UA的正确度验证通过，能够满足临床要求；该仪器检测各项目线性范围较宽，线性范围基本涵盖了临床样本分布的浓度范围,线性符合要求。 综上所述，雅培C800全自动生化分析仪检测BUN、CREN、UA各项性能均已达到国家卫生行业标准要求，是一台具有检测精度高、速度快、功能强等优点的全自动生化分析仪，能够满足各大、中型医院的临床检测需求。 【参考文献】 [1]张丽霞，孙艳虹，孙芹敏等．中华人民共和国卫生行业标准（WS/T 225-2002）《临床化学检验血液标本的收集与处理》[S]．北京：中国标准出版社，2002． XXXX系统性能测试报告 1 项目背景 为了了解XXXX系统的性能，特此对该网站进行了压力测试2 编写目的 描述该网站在大数据量的环境下，系统的执行效率和稳定性3 参考文档 4 参与测试人员 5 测试说明 5.1 测试对象 XXXX系统 5.2 测试环境结构图 5.3 软硬件环境 XXXXX 6 测试流程 1、搭建模拟用户真实运行环境 2、安装HP-LoadRunner11.00（以下简称LR） 3、使用LR中VuGen录制并调试测试脚本 4、对录制的脚本进行参数化 5、使用LR中Controller创建场景并执行 6、使用LR中Analysis组件分析测试结果 7、整理并分析测试结果，写测试总结报告 7 测试方法 使用HP公司的性能测试软件LoadRunner11.00，对本系统业务进行脚本录制，测试回放，逐步加压和跟踪记录。测试过程中，由LoadRunner的管理平台调用各前台测试，发起 各种组合业务请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。录制登陆业务模块，并模拟30、50、80、100 个虚拟用户并发登陆、添加和提交操作，进行多次连续测试，完成测试目标。 测试评估及数据统计 此次测试通过同一台客户机模拟多个并发用户在因特网环境进行，未考虑因特网的稳定 性的问题。此次测试用户操作流程相对简单，只录制了三个事务，即：用户登录、添加和信息提交，从测试的数据来分析，各项性能指标基本在可控的范围之内。但在测试过程中也发 现一些不容忽视的问题，应予以重视。 1 、模拟80 个用户并发操作时，出现1 个未通过的事务，具体原因需结合程序、网络和服务器综合分析，系统的稳定性并非无可挑剔。 2 、用户登陆事务的平均响应时间与其他两个事务相比等待的时间要长，且波动也较大， 在网速变慢、用户数增加的外部条件下，有可能会影响到系统的稳定性。建议优化系统登录页面程序，提高系统的稳定性。 Web性能测试方案 1测试目的 此处阐述本次性能测试的目的，包括必要性分析与扩展性描述。 性能测试最主要的目的是检验当前系统所处的性能水平，验证其性能是否能满足未来应用的需求，并进一步找出系统设计上的瓶颈，以期改善系统性能，达到用户的要求。 2测试范围 此处主要描述本次性能测试的技术及业务背景，以及性能测试的特点。 编写此方案的目的是为云应用产品提供web性能测试的方法，因此方案内容主要包括测试环境、测试工具、测试策略、测试指标与测试执行等。 2.1测试背景 以云采业务为例，要满足用户在互联网集中采购的要求，实际业务中通过云采平台询报价、下单的频率较高，因此云采平台的性能直接决定了业务处理的效率，并能够支撑业务并发的压力。 例如：支撑100家企业用户的集中访问，以及业务处理要求。 2.2性能度量指标 响应时间（TTLB） 即“time to last byte”，指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。响应时间＝网络响应时间+应用程序响应时间。 响应时间标准： 事务能力TPS（transaction per second） 服务器每秒处理的事务数； 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。 客户机在发送请求时开始计时，收到服务器响应后结束计时，一次来计算使用的时间和完成的事务个数。它是衡量系统处理能力的重要指标。 并发用户数 同一时刻与服务器进行交互的在线用户数量。 吞吐率（Throughput） 单位时间内网络上传输的数据量，也可指单位时间内处理的客户端请求数量，是衡量网络性能的重要指标。 吞吐率=吞吐量/传输时间 资源利用率 这里主要指CPU利用率（CPU utilization），内存占用率。 3测试内容 此处对性能测试整体计划进行描述，包括测试内容以及关注的性能指标。Web性能测试内容包含：压力测试、负载测试、前端连接测试。 3.1负载测试 负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大 XXXX性能测试 页脚内容1 目录 1.文档介绍 (4) 1.1 文档目的 (4) 1.2 参考文献 (4) 1.3编写目的 (4) 2.性能相关描述 (5) 2.1性能测试指标 (5) 2.2性能测试范围 (5) 2.3 名词术语约定 (6) 页脚内容2 3 测试环境 (7) 3.1生产环境系统架构 (7) 3.2测试环境系统架构 (8) 3.3 生产环境软硬件配置 (9) 3.4 测试环境软硬件配置 (9) 3.5 负载机软硬件配置 (10) 4.需求分析 (11) 4.1业务模型 (11) 4.2 性能指标 (12) 5 测试策略 (14) 5.1测试执行策略 (15) 5.2 测试监控策略 (16) 6测试场景 (17) 6.1前台开单测试场景 (17) 7测试准备 (19) 7.1测试工具准备 (19) 7.2测试脚本及程序准备 (20) 页脚内容3 7.3测试数据准备 (21) 7.4测试环境准备 (21) 8测试组织架构 (22) 9项目风险 (23) 1.文档介绍 1.1 文档目的 本测试报告为XXX平台项目的性能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合性能需求。 1.2 参考文献 1.3编写目的 从文档描述XXX发布系统性能测试的范围、方法、资源、进度，作为XXX发布系统性能测试的依据，该文档的目的主要有： 1、明确测试范围、测试对象 2、明确测试目标 3、明确测试环境需求，包括：测试需要的软、硬件环境以及测试人力需求 4、确定测试方案，测试的方法和步骤 页脚内容4 5、指定测试工作的时间安排 6、分析测试的风险，寻找规避办法 7、确定测试需求输出的结果和结果表现形式 2.性能相关描述 2.1性能测试指标 (1).基于XXX业务量的要求,评估XXX平台是否能满足性能要求 (2).进行配置测试,找到相对合理的测试 (3).对XXX进行定容定量,提供规划参考 (4).验证系统的稳定性,验证系统的容错能力 (5).测试并找到系统可能存在的性能问题,分析系统瓶颈 2.2性能测试范围 通过性能测试需求调研,分析用户使用行为.对系统的用户及业务数据量作了定量分析,性能测试将主要集中在表A-1中列出的业务过程. 表A-1 测试范围 页脚内容5 ×××系统项目 性能测试报告 ―――――――――――――――――――― XXX部 XXXXXXXX XXXX有限公司 修订控制页 目录 1.测试目的 (4) 2.测试地点 (4) 3.测试环境 (4) 3.1.服务器、客户端环境 (4) 3.2.测试工具 (5) 4.测试规模及限制 (5) 5.测试过程说明 (5) 5.1.测试模型 (5) 5.2.测试案例 (6) 5.3.测试场景 (6) 6.测试结果 (7) 6.1.平均响应时间 (7) 6.2.差错率统计 (9) 6.3.主机系统资源消耗 (10) 7.性能测试总结 (10) 8.大数据量业务测试数据 (11) 8.1.测试参数 (11) 8.2.测试结果 (11) 1.测试目的 本报告是针对XXX系统的功能完整性、高可靠性的集群、系统容量等多方面而进行的。其目的主要是验证系统架构设计决策的正确性，检验架构设计是否有能力承受高并发登录系统进行交易和大数据量的批量处理业务，根据用户提出的业务需求组织利用典型业务来验证XXX系统是否能够适应，发现现有系统中可能存在的性能方面问题，提出可行性建议，以尽可能降低后续工作风险，为系统的稳定运行提供保证。 主要测试目标如下： 1、获得XXX系统的性能表现，为系统上线提供依据。 2、考查XXX系统的并发性和效率情况，为代码优化提供指导。 3、获得系统性能较优的参数配置，为XXX系统调优提供依据。 4、获得XXX系统在不同负载下的主机资源消耗情况，为硬件配置提供依据。 2.测试地点 ××。 3.测试环境 3.1.服务器、客户端环境 本次测试的服务器环境为XXX系统的生产主机，客户环境为1台P4 1.6G 的便携式笔记本。 本次测试使用的设备清单如下： 基于Web系统的性能测试 摘要：Web应用系统具有方便、快速、易操作性等特点，使得社会中的各行业越来越倾向于使用Web应用系统开展自身业务以及扩大社会影响力。随着Web应用系统的广泛使用，用户对性能的要求越来越高。该文主要介绍了Web应用系统的关键性能指标及测试方法，结合案例评估和分析Web应用系统性能的过程。 关键词：Web应用系统性能测试性能指标LoadRunner 中图分类号：TP311 文献标识码：A 文章编号： 1007-9416（2014）04-0156-02 基于Web的应用系统在当今互联网盛行的时代被广泛应用于社会的各个领域，比如：教育行业、交通系统、移动通信、金融系统以及政府部门等各个领域。由于Web系统所具有的快捷、易使用的特点，使得社会中人们对Web系统更加依赖，也促使了社会各个领域对Web应用系统的重视，纷纷把原有的业务操作模式网络化。但是在网络化的过程中，随着工作流的增加、使用人员的增多以及业务数据量的剧增，问题也随之而来：如果交互的信息量过大，经常会导致系统反应速度骤降或者系统宕机。因此，社会各领域中的Web应用系统能否承受住大量的数据访问以及业务操作、并 能够快速地响应使用者的请求、系统能否长时间稳定地运行，系统的性能瓶颈所在，这些都是用户所关心的性能表现。性能测试的目的是检测系统性能是否符合用户的需求，有无性能方面的瓶颈；所以性能测试是项目建设过程中重要的一环。测试方法一般采用负载测试、压力测试等方法。 1 性能测试简介 性能测试考察的是通过性能指标验证系统有无性能问题。测试方法主要包括负载测试、压力测试、大数据量测试、疲劳强度测试等。在测试过程中通常是模拟真实用户使用环境下的负载量，统计分析系统各方面的性能数据，得出性能测试结论。在实际的测试工作中，通常要结合几种测试方法，综合分析测试过程中体现出来的各种数据。 1.1 性能测试类型 （1）负载测试：是在系统真实的用户环境下或模拟系统真实运行环境及用户真实业务使用场景情况下，通过不断给系统增加压力，在一定压力下延长系统运行时间，来验证系统各项性能指标的变化情况，直到系统性能出现拐点。目前一般采用业内经常使用的测试工具LoadRunner来执行测试。当然也可以采用其他的测试工具。本文是利用LoadRunner进行测试。 （2）压力测试：是对系统不断增加负载，让系统在处于极限负载的情况下或者是某项指标已经处于饱和的状态 检测系统方法学验证程序 1. 原则 1.1 所有检验系统在正式投入患者样本检测之前，应确定其方法学性能，验证检测系统满足实验室对该项目的性能要求，适合预期用途。 1.2 实验室必须验证或建立每一试验项目的分析准确度、不精密度、分析灵敏度、分析特异性（干扰）和可报告范围。实验室可以使用厂家信息、出版的资料或其他实验室的研究结果，适用时，实验室需验证外部的信息。 1.3 美国食品药品监督管理局（FDA ）批准的未经任何改动的检测系统，可以通过验证程序确认其方法学性能；美国食品药品监督管理局（FDA ）批准的但有所改动的检测系统，必须全面评价和建立其方法学性能。 1.4 某一暂停试验重新应用，重新开始患者样本检测前30 天内进行方法学性能验证。 2. 方法学验证实验 2.1 检验方法投入使用前，应验证的方法学性能指标包括：精密度、准确度、分析灵敏度、分析特异性（干扰）、分析检测范围（AMR）、可报告范围。 2.2 实验室对于所开展的每一检测项目和样本来源，应建立或验证所服务人群的参考区间。 2.3 对于带有自动移液系统的仪器设备，在投入使用前或大的维护保养及移液系统维修后应进行携带污染的评估实验。 2.4 实验室应明确规定进行方法学验证实验的标准，明确规定在什么情况下需要进行相关的方法学验证实验。 3. 方法学验证参考方案 3.1 准确度 3.1.1 与决定性或参考方法检测结果进行比较而建立； 3.1.2 检测参考物质； 3.1.3 与已建立可比性的方法进行结果比较而验证； 3.1.4 其他已知浓度或活性的物质。 3.2 精密度 3.2.1 可重复检测不同浓度或活性水平的患者样本进行批内精密度验证；使用室内 xxxxxxxxxxxxxxx 系统测试报告 xxxxxxxxxxx公司 20xx年xx月 版本修订记录 目录 1引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3术语解释 (1) 1.4参考资料 (1) 2测试概要 (2) 2.1系统简介 (2) 2.2测试计划描述 (2) 2.3测试环境 (2) 3测试结果及分析 (3) 3.1测试执行情况 (3) 3.2功能测试报告 (3) 3.2.1系统管理模块测试报告单 3 3.2.2功能插件模块测试报告单 4 3.2.3网站管理模块测试报告单 4 3.2.4内容管理模块测试报告单 4 3.2.5辅助工具模块测试报告单 4 3.3系统性能测试报告 (4) 3.4不间断运行测试报告 (5) 3.5易用性测试报告 (5) 3.6安全性测试报告 (6) 3.7可靠性测试报告 (6) 3.8可维护性测试报告 (7) 4测试结论与建议 (9) 4.1测试人员对需求的理解 (9) 4.2测试准备和测试执行过程 (9) 4.3测试结果分析 (9) 4.4建议 (9) 1引言 1.1 编写目的 本测试报告为xxxxxx软件项目的系统测试报告，目的在于对系统开发和实施后的的结果进行测试以及测试结果分析，发现系统中存在的问题，描述系统是否符合项目需求说明书中规定的功能和性能要求。 预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。 1.2 项目背景 ?项目名称：xxxxxxx系统 ?开发方： xxxxxxxxxx公司 1.3 术语解释 系统测试：按照需求规格说明对系统整体功能进行的测试。 功能测试：测试软件各个功能模块是否正确，逻辑是否正确。 系统测试分析：对测试的结果进行分析，形成报告，便于交流和保存。 1.4 参考资料 1)GB/T 8566—2001 《信息技术软件生存期过程》(原计算机软件开发规范) 2)GB/T 8567—1988 《计算机软件产品开发文件编制指南》 3)GB/T 11457—1995 《软件工程术语》 4)GB/T 12504—1990 《计算机软件质量保证计划规范》 5)GB/T 12505—1990 《计算机软件配置管理计划规范》 Xxx项目_性能测试报告 一、概述 1.1 测试对象 web系统 1.2 测试目的 确定系统支持的最大并发用户数 1.3 测试环境 序 号 用途硬件环境软件环境 1 测试用机CPU PIII733 RAM 256M Win2000server + sp4 测试工具（loadrunner7.5） 2 web服务器（被 测系统）CPU P4 1Ghz RAM 256M Win2000server + sp4 Weblogic 6.1 3 数据库服务器 （被测系统）CPU P4 1.7Ghz RAM 512M Win2000server + sp4 Oracle 9i 1.4 测试依据 序号名称/版本 1.5 参考资料 序号名称/版本编制日期作者/来源 1 N/A N/A N/A 1.6 术语及缩写词 ●测试时间：一轮测试从开始到结束所使用的时间 ●并发线程数：测试时同时访问被测系统的线程数。注意，由于测试过程中，每个线程都是以尽可 能快的速度发请求，与实际用户的使用有极大差别，所以，此数据不等同于实际使用时的并发用户数。 ●每次时间间隔：测试线程发出一个请求，并得到被测系统的响应后，间隔多少时间发出下一次请 求。 ●平均响应时间：测试线程向被测系统发请求，所有请求的响应时间的平均值。 ●处理能力：在某一特定环境下，系统处理请求的速度。 ●cache影响系数：测试数据未必如实际使用时分散，cache在测试过程中会比实际使用时发挥更大 作用，从而使测试出的最高处理能力偏高，考虑到这个因素而引入的系数。 ●用户习惯操作频率：根据用户使用习惯估算出来的，单个用户在一段时间内，使用此类功能的次 数。通常以一天内某段固定的高峰使用时间来统计，如果一天内没有哪段时间是固定的高峰使用时间，则以一天的工作时间来统计。 ●预期平均响应时间：由用户提出的，希望系统在多长时间内响应。注意，这个值并不是某一次访 问的时间，而是一段时间多次访问后的平均值。 ●最大并发用户数：在给定的预期平均响应时间下，系统最多能支持多少个并发用户。这个数据就 是实际可以同时使用系统的用户数。 1.7 计算公式 ●成功率＝成功次数÷（成功次数＋失败次数） ●处理能力＝成功次数÷测试时间 ●最短平均响应时间＝MIN（平均响应时间） ●最高处理能力＝MAX（处理能力）×（1－cache影响系数） ●最大并发用户数＝（最高处理能力－1÷（预期平均响应时间－最短平均响应时间＋（1÷最高 处理能力）））÷用户习惯操作频率，此公式要注意各时间单位的不同和转换 2.测试方法 2.1 测试模型 2.2 测试过程简述 通过编写特定的测试流程，使用多线程技术，模拟多个浏览器持续一段时间并发访问被测系统，记录系 性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则； 一、WEB 全面性能测试模型 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过2 0秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 2. 独立业务性能测试 独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。 用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。 3. 组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。 用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配； 4. 疲劳强度性能测试 疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定； 5. 大数据量性能测试 一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试； 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。 第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试； 大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试； 6. 网络性能测试 主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中 主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成； 7. 服务器（操作系统，WEB服务器，数据库服务器）性能测试 WEB Tours订票系统性能测试报告 姓名： 班级： 学号： 指导老师： 目录 1 前言 (2) 2 被测系统定义 (4) 功能简介 (4) 性能测试指标............................. 错误!未定义书签。 3 系统结构及流程 (5) 系统总体结构 (5) 关键点描述 (5) 性能测试环境 (5) 4 性能测试 (5) 性能测试概述 (6) 测试目的 (6) 测试方法及测试用例....................... 错误!未定义书签。 测试指标及期望 (7) 测试数据准备 (8) 运行状况记录 (8) 5 测试过程及结果描述 (8) 测试描述 (9) 测试场景 (9) 测试结果 (13) 6测试分析和结论 (25) 1前言 目前，WEB Tours订票系统成功上线，从而航空公司的机票信息管理逐步走上了集中管控的道路，从而将会势必出现新业务系统中信息大量增长的态势。 随着新业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：大数据量的“冲击”，在多名用户信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。 本报告前部分即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的WEB Tours订票系统的性能测试。 2被测系统定义 WEB Tours订票系统作为本次测试的被测系统，该订票系统的主要功能包括：注册和登录用户信息，订票办理，退票办理，查询客户已订票信息等。在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数， XXXXX项目 压力测试报告 2015-10-16 XXXXXX技术有限公司文档信息 批复信息 版本记录 1简介 1.1 文档目的 本测试报告为性能对比测试报告，目的在于总结测试的工作进展情况并分析测试结果，描述本阶段测试是否达到调优预期目标，符合需要要求。 1.2 面向人员 本文档主要面向XX系统用户、测试人员、开发人员、项目管理人员和需要阅读本报告的相关领导。 1.3 参考文档 1.4 术语 1.每秒事务数（TPS）：是指每秒钟完成的事务数，事务是事先在脚本中定义的统计单元； 2.事务平均响应时间（ART）：响应时间一般反映了在并发情况下，客户端从提交请求到接受到应答所经历的时间； 3.资源利用率：是指在不影响系统正常运行的情况下各服务器的CPU、内存等硬件资源的占用情况； 4.最大并发用户数：系统所能承受的最大并发用户数； 5.思考时间（Thinktime）：用于模拟实际用户在不同操作之间等待的时间。例如，当用户收到来自服务器的数据时，可能要等待几秒钟查看数据，然后做出响应，这种延时就称为“思考时间”。 2第一轮测试目标 根据项目情况，本次测试的目的主要是解决XX系统个人系统登录和理财交易的处理能力达到客户正常使用要求，根据测试结果评估系统性能，为生产运行提供参考。 1）分析目前系统登录与理财的处理能力； 2）提高登录和理财交易处理能力，达到客户流畅使用的目的； 3第二轮测试安排 1、对整体系统运行环境、系统自身交易功能进行全面分析。通过 压力测试手段优化系统，提高运行效率，并给出未来三到五年 资源配置计划，制定后续保障机制。 2、计划从十月十九日开始方案讨论。 Xxxx 性能测试报告 文档编号： 密级： 版本信息：Vxxxx 建立日期：2017-06 创建人：XXX 1引言 1.1编写目的 根据性能测试方案，给出结果和分析以及结论和建议。 测试方案预期读者：开发人员、测试人员、和项目相关人员。 1.2项目背景 1.3术语定义 虚拟用户：通过执行测试脚本模仿真实用户与被测试系统进行通信的进程或线程。 测试脚本：通过执行特定业务流程来模拟真实用户操作行为的脚本代码。 场景：通过组织若干类型、若干数量的虚拟用户来模拟真实生成环境中的负载场景。 集合点：用来确定某一步操作由多少虚拟用户同步执行（并发）。 事务：设置事务是为了明确某一个或多个业务或者某一个按钮操作的响应时间。 HPS:每秒点击数，一般情况下，与TPS成正比。 TPS：每秒事务数，是指每秒内，每个事务通过、失败以及停止的次数，可以确定系统在任何给定时刻的实际事务负载。 系统资源利用率：是指在对被测试系统执行性能测试时，系统部署的相关应用服务器、数据库等系统资源利用，比如CUP，内存，网络等。 2测试业务及性能需求 服务器配置如下： Web服务器： 操作系统：Windows7 旗舰版64位； 处理器：Intel(R) Xeon(R) CPUI5 -5200U@2.20GHz 2.20GHz 3场景设及计执行结果 3.1场景设计 3.2测试结果 3.2.1“提交”事务情况汇总 3.2.2每秒点击量（hps） 1、CJ-TJ_001和CJ-TJ_004点击率在大概维持在13-15左右的点击率 2、CJ-TJ_003和CJ-TJ_004点击率在场景持续变发60或者80个用户时，hPS会有明显的下降7600生化分析仪检测系统的性能验证
软件系统测试报告(实用版)
web项目测试实战性能测试结果分析样章报告
雅培ARCHEITECT C800全自动生化分析仪检测系统性能验证
XX系统性能测试报告
Web性能测试方案
web性能测试计划
性能测试报告模板
基于Web系统的性能测试
新检测系统性能验证程序
系统测试报告
WEB性能测试报告
WEB性能测试方法
WEB-Tours订票系统性能测试报告
系统调优性能测试报告讲解
web端性能测试报告