51Testing软件测试论坛
标题:
借论坛请教个Linux的监控内存问题
[打印本页]
作者:
330254601
时间:
2011-12-30 16:28
标题:
借论坛请教个Linux的监控内存问题
现在想在Linux系统中监控几个服务的占用内存的情况
有什么工具或方法能查看这些服务的内存动态变化?
作者:
330254601
时间:
2011-12-30 19:17
我们使用top命令来查看CPU使用状况。
top不会产生输出,屏幕内容保持不变。它刷新屏幕以显示新信息。因此,如果您只执行top并保持屏幕一直开启,则屏幕始终显示最新信息。退出top的命令为q,或者按下Ctrl-C.
top - 17:03:45 up 58 days, 4:01, 1 user, load average: 0.00, 0.02, 0.00
Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.1% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4037036k total, 4007280k used, 29756k free, 93384k buffers
Swap: 8385888k total, 71536k used, 8314352k free, 3068240k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27167 oracle 16 0 2011m 490m 483m S 1 12.4 0:46.93 oracle
27175 oracle 15 0 2011m 517m 510m S 1 13.1 0:49.78 oracle
5003 oracle 15 0 2021m 33m 29m S 0 0.9 3:56.10 oracle
1 root 16 0 4756 552 460 S 0 0.0 0:09.31 init
2 root RT 0 0 0 0 S 0 0.0 0:00.47 migration/0
...............................
第一行(top):
top - 17:03:45 up 58 days, 4:01, 1 user, load average: 0.00, 0.02, 0.00
“17:03:45”为系统当前时刻;
“58 days, 4:01”为系统启动后到现在的运作时间;
“1 user”为当前登录到系统的用户,更确切的说是登录到用户的终端数--同一个用户同一时间对系统多个终端的连接将被视为多个用户连接到系统,这里的用户数也将表现为终端的数目;
“load average”为当前系统负载的平均值,后面的三个值分别为1分钟前、5分钟前、15分钟前进程的平均数,一般的可以认为这个数值超过CPU数目时,CPU将比较吃力的负载当前系统所包含的进程;
第二行(Tasks):
“172 total”为当前系统进程总数;
“1 running”为当前运行中的进程数;
“171 sleeping”为当前处于等待状态中的进程数;
“0 stoped”为被停止的系统进程数;
“0 zombie”为僵死的进程数;
第三行(Cpus):
显示CPU利用率的详细信息,如果有多个CPU,屏幕将在每行显示一个CPU的信息。
第四行(Mem):
显示可用的和已利用的内存
第五行(Swap):
表示类别同第四行(Mem),但此处反映着交换分区(Swap)的使用情况。通常,交换分区(Swap)被频繁使用的情况,将被视作物理内存不足而造成的。
其余的显示内容以表格格式显示进程。下面对各列进行解释:
列描述
PID 进程的进程ID
USER 运行该进程的用户
PRI 进程的优先级
NI nice值:该值越高,任务的优先级越低
SIZE 该进程使用的内存(代码+数据+堆栈)
RSS 该进程使用的物理内存
SHARE 该进程使用的共享内存
STAT 该进程的状态,用代码显示。一些主要的状态代码包括:
R— 正在运行
S— 正在休眠
Z— 迟滞
T— 已停止
您还会看到第二个和第三个字符,它们表示:
W— 已换出的进程
N— 正nice值
%CPU 该进程使用的CPU百分比
%MEM 该进程使用的内存百分比
TIME 该进程使用的总CPU时间
CPU 如果这是一个多处理器系统,该列指明正在其上运行进程的CPU的ID。
COMMAND 该进程发出的命令
top运行中可以通过top的内部命令对进程的显示方式进行控制。内部命令如下:
s -改变画面更新频率
l -关闭或开启第一部分第一行top信息的表示
t -关闭或开启第一部分第二行Tasks和第三行Cpus信息的表示
m -关闭或开启第一部分第四行Mem和第五行Swap信息的表示
N -以PID的大小的顺序排列表示进程列表
P -以CPU占用率大小的顺序排列进程列表
M -以内存占用率大小的顺序排列进程列表
h -显示帮助
n -设置在进程列表所显示进程的数量
q -退出top
---------------------------------------------------------
动态查看一个进程的内存使用
view plaincopy to clipboardprint?
01.1、top命令
02.top -d 1 -p pid [,pid ...] //设置为delay 1s,默认是delay 3s
03.如果想根据内存使用量进行排序,可以shift + m(Sort by memory usage)
静态查看一个进程的内存使用
view plaincopy to clipboardprint?
01.1、pmap命令
02.pmap pid
03.
04.2、ps命令
05.ps aux|grep process_name
06.
07.3、查看/proc/process_id/文件夹下的status文件
08.Name: php
09.State: R (running)
10.SleepAVG: 0%
11.Tgid: 21574
12.Pid: 21574
13.PPid: 10005
14.TracerPid: 0
15.Uid: 1000 1000 1000 1000
16.Gid: 100 100 100 100
17.FDSize: 256
18.Groups: 16 100
19.VmPeak: 161740 kB
20.VmSize: 161740 kB
21.VmLck: 0 kB
22.VmHWM: 107144 kB
23.VmRSS: 107144 kB
24.VmData: 106192 kB
25.VmStk: 84 kB
26.VmExe: 5588 kB
27.VmLib: 7884 kB
28.VmPTE: 268 kB
29.Threads: 1
30.SigQ: 0/69632
31.SigPnd: 0000000000000000
32.ShdPnd: 0000000000000000
33.SigBlk: 0000000000000000
34.SigIgn: 0000000000001000
35.SigCgt: 00000001818040a7
36.CapInh: 0000000000000000
37.CapPrm: 0000000000000000
38.CapEff: 0000000000000000
39.Cpus_allowed: 00000000,00000000,00000000,0000000f
40.Mems_allowed: 1
41.
42.任务虚拟地址空间的大小 VmSize
43.应用程序正在使用的物理内存的大小 VmRSS
作者:
330254601
时间:
2011-12-30 19:18
我们使用top命令来查看CPU使用状况。
top不会产生输出,屏幕内容保持不变。它刷新屏幕以显示新信息。因此,如果您只执行top并保持屏幕一直开启,则屏幕始终显示最新信息。退出top的命令为q,或者按下Ctrl-C.
top - 17:03:45 up 58 days, 4:01, 1 user, load average: 0.00, 0.02, 0.00
Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.1% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4037036k total, 4007280k used, 29756k free, 93384k buffers
Swap: 8385888k total, 71536k used, 8314352k free, 3068240k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27167 oracle 16 0 2011m 490m 483m S 1 12.4 0:46.93 oracle
27175 oracle 15 0 2011m 517m 510m S 1 13.1 0:49.78 oracle
5003 oracle 15 0 2021m 33m 29m S 0 0.9 3:56.10 oracle
1 root 16 0 4756 552 460 S 0 0.0 0:09.31 init
2 root RT 0 0 0 0 S 0 0.0 0:00.47 migration/0
...............................
第一行(top):
top - 17:03:45 up 58 days, 4:01, 1 user, load average: 0.00, 0.02, 0.00
“17:03:45”为系统当前时刻;
“58 days, 4:01”为系统启动后到现在的运作时间;
“1 user”为当前登录到系统的用户,更确切的说是登录到用户的终端数--同一个用户同一时间对系统多个终端的连接将被视为多个用户连接到系统,这里的用户数也将表现为终端的数目;
“load average”为当前系统负载的平均值,后面的三个值分别为1分钟前、5分钟前、15分钟前进程的平均数,一般的可以认为这个数值超过CPU数目时,CPU将比较吃力的负载当前系统所包含的进程;
第二行(Tasks):
“172 total”为当前系统进程总数;
“1 running”为当前运行中的进程数;
“171 sleeping”为当前处于等待状态中的进程数;
“0 stoped”为被停止的系统进程数;
“0 zombie”为僵死的进程数;
第三行(Cpus):
显示CPU利用率的详细信息,如果有多个CPU,屏幕将在每行显示一个CPU的信息。
第四行(Mem):
显示可用的和已利用的内存
第五行(Swap):
表示类别同第四行(Mem),但此处反映着交换分区(Swap)的使用情况。通常,交换分区(Swap)被频繁使用的情况,将被视作物理内存不足而造成的。
其余的显示内容以表格格式显示进程。下面对各列进行解释:
列描述
PID 进程的进程ID
USER 运行该进程的用户
PRI 进程的优先级
NI nice值:该值越高,任务的优先级越低
SIZE 该进程使用的内存(代码+数据+堆栈)
RSS 该进程使用的物理内存
SHARE 该进程使用的共享内存
STAT 该进程的状态,用代码显示。一些主要的状态代码包括:
R— 正在运行
S— 正在休眠
Z— 迟滞
T— 已停止
您还会看到第二个和第三个字符,它们表示:
W— 已换出的进程
N— 正nice值
%CPU 该进程使用的CPU百分比
%MEM 该进程使用的内存百分比
TIME 该进程使用的总CPU时间
CPU 如果这是一个多处理器系统,该列指明正在其上运行进程的CPU的ID。
COMMAND 该进程发出的命令
top运行中可以通过top的内部命令对进程的显示方式进行控制。内部命令如下:
s -改变画面更新频率
l -关闭或开启第一部分第一行top信息的表示
t -关闭或开启第一部分第二行Tasks和第三行Cpus信息的表示
m -关闭或开启第一部分第四行Mem和第五行Swap信息的表示
N -以PID的大小的顺序排列表示进程列表
P -以CPU占用率大小的顺序排列进程列表
M -以内存占用率大小的顺序排列进程列表
h -显示帮助
n -设置在进程列表所显示进程的数量
q -退出top
---------------------------------------------------------
动态查看一个进程的内存使用
view plaincopy to clipboardprint?
01.1、top命令
02.top -d 1 -p pid [,pid ...] //设置为delay 1s,默认是delay 3s
03.如果想根据内存使用量进行排序,可以shift + m(Sort by memory usage)
静态查看一个进程的内存使用
view plaincopy to clipboardprint?
01.1、pmap命令
02.pmap pid
03.
04.2、ps命令
05.ps aux|grep process_name
06.
07.3、查看/proc/process_id/文件夹下的status文件
08.Name: php
09.State: R (running)
10.SleepAVG: 0%
11.Tgid: 21574
12.Pid: 21574
13.PPid: 10005
14.TracerPid: 0
15.Uid: 1000 1000 1000 1000
16.Gid: 100 100 100 100
17.FDSize: 256
18.Groups: 16 100
19.VmPeak: 161740 kB
20.VmSize: 161740 kB
21.VmLck: 0 kB
22.VmHWM: 107144 kB
23.VmRSS: 107144 kB
24.VmData: 106192 kB
25.VmStk: 84 kB
26.VmExe: 5588 kB
27.VmLib: 7884 kB
28.VmPTE: 268 kB
29.Threads: 1
30.SigQ: 0/69632
31.SigPnd: 0000000000000000
32.ShdPnd: 0000000000000000
33.SigBlk: 0000000000000000
34.SigIgn: 0000000000001000
35.SigCgt: 00000001818040a7
36.CapInh: 0000000000000000
37.CapPrm: 0000000000000000
38.CapEff: 0000000000000000
39.Cpus_allowed: 00000000,00000000,00000000,0000000f
40.Mems_allowed: 1
41.
42.任务虚拟地址空间的大小 VmSize
43.应用程序正在使用的物理内存的大小 VmRSS
作者:
330254601
时间:
2011-12-31 09:32
回复
5#
szyszy2000
上面那个top命令和我现在使用的linux不一样
我想问下 如果我具体想操作监控26874这个进程的内存使用情况,可以使用什么方法查看到?能转储成文件在本地查看最好。
麻烦详细说下具体操作嘛,谢谢
作者:
330254601
时间:
2012-1-8 20:05
http://linuxeden.com/doc/24305.html
Linux压力测试与LTP体系结构
一、几个问题
开始正题之前,我们先看几个问题:什么是稳定性和可靠性?什么是压力测试?为什么要进行压力测试?
什么是稳定性和可靠性?
稳定性反映的是系统不会出现异常情况;可靠性反映的是系统能够保持正常运行而不受外界影响的能力。
系统的稳定性和可靠性通常以连续运转时间和系统的可靠运行时间来度量。
什么是压力测试?
压力测试是一种破坏性的测试,即系统在非正常的、超负荷的条件下的运行情况 。用来评估在超越最大负载的情况下系统将如何运行,是系统在正常的情况下对某种负载强度的承受能力的考验 。
为什么要进行压力测试?
通常我们用压力测试来判断系统的稳定性和可靠性。
了解了上面的问题之后,我们来看看该如何进行压力测试的设计。
二、压力测试的设计
在对Linux内核版本稳定性的测试中,需要明确地声明并证明为什么该版本是稳定的或者是不稳定的。不同的 Linux 开发者、 用户和发行商会使用他们自己的方法来测试内核的稳定性,但是,如果他们对运行了哪些测试、覆盖的代码、达到的压力级别等的基础信息都没有发布,那么这就会大大降低了结果的价值。
为此要有一个合适的测试方法来规范Linux内核稳定性的测试,以系统资源的利用率统计为基准制定了一个组合的测试方法,这一组合测试方法的四个步骤是:测试选择、系统资源利用率评价、内核代码覆盖分析以及最终的压力测试评价。
1 测试选择
测试选择包括达成两方面目的的测试:
- 测试应该可以得到 CPU(s)、内存、I/O 和网络等主要内核区域的高水平的资源利用率。
- 测试应该充分地覆盖内核代码,以帮助支持自其结果中生成的稳定性声明。
2 评价系统资源利用率
所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面可以影响系统的 响应和执行时间:
- CPU:用于在机器的 CPU(s)上处理数据的时间。
- Memory:用于自真实存储器中读写数据的时间。
- I/O:用于自磁盘存储器读写数据的时间。
- Networking:用于自网络读写数据的时间。
系统资源利用率评价阶段通常需要多次尝试才能得到合适的测试组合,并得到期望水平的利用率。当确定测试组合时,过度利用总是一个至关重要的问题。例如,如果选择的组合过于受 I/O 所限,可能会 导致 CPU 的测试结果不好,反之亦然。方法的这一部分主要是大量的试验和出错,直到所有资源达到期望水平。
当选定一个组合后,测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每个测试的长度。假如多个测试同时运行,则时间必须足够长以使得这些测试中最长的那个可以完成。在这个评价过程中,sar 工具也应该在运行。在评价运行的结论中,您应该收集并评价所有四种资源的利用率水平。
3 分析内核代码覆盖率
获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源,它也有可能只是执行了内核的一小部分。因而,应该对覆盖率进行分析以确保组合可以成为一个系统压力测试,而不是一个系统负载生成器。
4 评价最终压力测试
之所以要执行方法中的这最后一步,是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试; 通常,发行版本中的内核可以满足这一要求,但不总是如此。要长时间地执行压力测试,同时运行sar 工具,原因有以下两点:
- 长时间运行有助于发现组合中的所有问题,否则,在短时间的“取样测试(sniff test)”中这些问题可能会被忽略。
- sar 生成的数据构成以后测试运行中进行比较的基线。
长时间运行结束后,现在可以基于收集的所有数据来决定这个测试组合是否是系统压力测试的合适候选者。
三、LTP(Linux Test Project)
LTP工作组在设计Linux 内核压力测试脚本 ltpstress.sh 时使用了这一设计方法,为给系统提供足够的压力,LTP工作组对这个组合测试进行了分析,以确定 Linux 内核的哪些部分在测试执行中得到了使用。然后,修改了组合测试,在保持期望的高强度系统压力的同时提高代码覆盖率的百分比。最终得到的压力测试涵盖了Linux 内核的足够多部分,有助于稳定性声明,并且有系统使用情况和内核代码覆盖情况的数据来支持它。
有两个开放源代码工具可以帮助进行 Linux 内核的代码覆盖率分析:
- gcov:一个由 LTP 维护的开放源代码工具。这个工具分析内核代码的覆盖率,并报告哪些行、函数和分支被覆盖以及它们被访问了多少次。
- lcov:另一个由 IBM 开发,由 LTP 维护的开放源代码工具。 这个工具由一组构建于基于文本的 gcov 输出之上的 Perl 脚本构成,以实现基于 HTML 的输出。输出包括覆盖率百分比、图表以及概述页,可以快速浏览覆盖率数据。可以自LTP主页找到这两个工具。
lcov 工具会生成一棵完整的 HTML 树,其中包含有内核中代码的每一行以及关于每一行执行了 多少次的数据(如果有的话)。这个工具会量化覆盖率数据并生成关于内核中每一部分和 文件覆盖率的百分比数字。
内核的代码覆盖率分析只是在ltpstress.sh的设计和开发过程中用到,目的是保证lptsress.sh的可用性,我们在实际测试的时候就不需要再做内核的代码覆盖率分析了。
1 LTP的ltpstress.sh目标
ltpstress.sh的目标,是使用 LTP 测试套件对Linux 操作系统进行超长时间的测试,重点在于Linux 用户环境相关的工作负荷,而并不是致力于证明缺陷。这个应用程序组合了来自 LTP 的测试套件不同方面的多个测试以及内存和网络传输负载生成器。在执行之前,测试会根据系统中存在多少物理和虚拟内存来调整其总的内存使用情况。
2 ltpstress.sh的测试方法
测试方法有两个的阶段:一个是“初始测试”,一个是“压力测试”。通过初始测试是开始测试的必要条件。初始测试包括 LTP 测试套件在硬件和操作系统上成功运转,这些硬件和操作系统将用于可靠性运转。LTP 测试套件包附带的驱动程序脚本 runalltest.sh 用于验证内核。这个脚本串行地运行一组成包的测试,并报告全部结果。也可以选择同时并行地运行几个实例。默认地,这个脚本执行:
- 文件系统压力测试。
- 硬盘 I/O 测试。
- 内存管理压力测试。
- IPC 压力测试。
- SCHED测试。
- 命令功能的验证测试。
- 系统调用功能的验证测试。
压力测试可以验证产品在系统高使用率时的健壮性。作为 runalltest.sh 的补充,特别设计了一个名为 ltpstress.sh 的测试场景,在使用网络与内存管理的同时并行地运行大范围的内核组件,并在测试系统上生成高压力负荷。ltpstress.sh 也是 LTP 测试套件的一部分。这个脚本并行地运行相似的测试用例,串行地运行不同的测试用例,这样做是为了避免由于同时访问同一资源或者互相干扰而引起的间歇性故障。默认地,这个脚本执行:
- NFS 压力测试。
- 内存管理压力测试。
- 文件系统压力测试。
- 数学 (浮点) 测试。
- 多线程压力测试。
- 硬盘 I/O 测试。
- IPC (pipeio, semaphore) 测试。
- 系统调用功能的验证测试。
- 网络压力测试。
3 系统监控
LTP 测试套件附带的 top 工具是经过修改的,用作系统监控工具。使用 top 可以实时地观察处理器的行为。改进的 top 工具具有附加的功能,可以将 top 结果的快照保存到文件中,并给出结果文件的平均总结,包括 CPU、内存和交换空间利用率等信息。
在我们的测试中,sar工具每 10 秒钟截取一次系统利用率的快照,并保存到结果文件。
测试之前所有选定的测试系统的硬件配置尽可能相同。去掉额外的硬件以减少潜在的硬件故障。在映像安装过程中选择最低的安全选项。预留至少 2 GB 的硬盘空间以保存 top 数据文件和 LTP 日志文件。
在测试期间系统不要受到干扰。偶尔访问一下系统以确认测试仍在进行是可以接受的。确认的手段包括使用 ps 命令、检查 top 数据和检查 LTP 日志数据。
4 LTP的结构
LTP的目录结构基本上分为文档目录(doc)、测试驱动程序目录(pan)、测试脚本目录(testscripts)、测试用例库(testcase)、测试命令文件目录(runtest)、头文件目录(include)、库目录(lib)等。
Doc:该目录是说明文件和帮助文档的所在地,这个目录中对LTP的内容和每个工具都有详细的说明。
Pan:该目录存储的是LTP测试套件的测试驱动程序pan。
Testscripts:该目录中存储的是可执行的测试脚本,不同方面的测试脚本的集合。
Testcase:该目录存储了所有LTP测试套件中所使用的测试用例的源码。
Runtest:该目录中的每个文件都是要执行的测试用例的命令集合,每个文件针对测试的不同方面。
Include:LTP测试套件的头文件目录,定义了LTP自身的数据结构和函数结构。
Lib:LTP测试套件运行时自身需要的库文件,定义了LTP自身的各种函数。
5 LTP 的测试方法
LTP测试套件有一个专门的测试驱动程序pan,具体的测试用例的执行都是由pan来调用执行,它可以跟踪孤儿进程和抓取测试的输出信息。它的工作方式是这样的:
从一个测试命令文件中读取要测试的条目的要执行的命令行,然后等待该项测试的结束,并记录详细的测试输出。默认状态下pan会随机的选择一个命令行来运行,可以指定在同一时间要执行测试的次数。
pan会记录测试产生的详细的格式复杂的输出,但它不进行数据的整理和统计,数据整理统计的工作由scanner来完成,scanner是一个测试结果分析工具,它会理解pan的输出格式,并输出成一个表格的
形式来总结那些测试passed或failed。
6 LTP的实际运行
实际运行当中,您还需要配置一些必要的服务才可以正确的运行LTP的测试套件,以ltprunall.sh为例,它是不需要配置其他服务就可以运行的,但是对于ltpstress.sh,是需要配置一些相关服务之后才可以正确运行的,需要您配置的服务如下:
配置rsh和rlogin服务,使用户能以root身份不需密码验证直接登录本机。
开启xinetd服务。
在用户主目录下建立一个名为.rhosts的文件,文件内容是允许对本机进行rsh和rlogin操作的主机名和IP地址。一个相应的例子如下:
# vi .rhosts
test.my.domain
192.168.1.11
localhost.localdomain
127.0.0.1
配置工作最后要做的就是重启xinetd服务,因为rsh和rlogin是受xinetd服务控制的:
/etc/init.d/ xinetd restart
或service xinetd restart
作者:
330254601
时间:
2012-1-8 20:06
然后您就可以运行ltpstress.sh的脚本了。通常用到的参数是 [-d outputfile] [-l logfile] [-t run-time] [-S],-S 选项用来在测试运行过程中使用sar工具来采样系统的性能输出。
四、top和sar的一点使用说明
最后,我们在讨论一下top工具和sar工具的一些用法。
Top : 显示系统当前的进程和其他状况
使用方式:top [-] [d delay] [q] [c] [S] [n]
说明:即时显示 process 的动态
-d 改变显示的更新速度,或是在交谈式指令列( interactive command)按d。
-q 没有任何延迟的显示速度,如果使用者是有 superuser 的权限,则 top 将会以最高的优先序执行。
-c 切换显示模式,共有两种模式,一是只显示执行档的名称,另一种是显示完整的路径与名称。
-S 累积模式,会将己完成或消失的子行程 ( dead child process ) 的 CPU time 累积起来。
-s 安全模式,将交谈式指令取消, 避免潜在的危机。
-i 不显示任何闲置 (idle) 或无用 (zombie) 的行程。
-n 更新的次数,完成后将会退出 top。
-b 批次档模式,搭配 "n" 参数一起使用,可以用来将 top 的结果输出到档案内。
范例:
显示更新十次后退出 ;
top -n 10
将更新显示二次的结果输入到名称为 top.log 的档案里 :
top -n 2 -b > top.log
sar:收集、报告、保存系统的活动信息
使用方式:sar [options] [-A] [-o file] t [n]
说明:在命令行中,n 和t 两个参数组合起来定义采样间隔和次数,t为采样间隔,是必须有的参数,n为采样次数,是可选的,sar命令的选项很多,下面只列出常用选项:
-a 报告文件读写使用情况
-b 报告缓存的使用情况
-c 报告系统调用的使用情况
-d 报告磁盘的使用情况
-h 报告关于buffer使用的统计数据
-m 报告IPC消息队列和信号量的使用情况
-q 报告运行队列和交换队列的平均长度
-R 报告进程的活动情况
-r 报告没有使用的内存页面和硬盘块
-u 报告CPU的利用率
-v 报告进程、i节点、文件和锁表状态
-w 报告系统交换活动状况
范例:
查看CPU的利用率,以2s为间隔,采样5次。
Sar -u 2 5
作者:
330254601
时间:
2012-1-8 20:14
# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 18916 MB in 1.99 seconds = 9484.20 MB/sec
Timing buffered disk reads: 586 MB in 3.00 seconds = 195.06 MB/sec
作者:
330254601
时间:
2012-1-8 20:22
一、 前言
在 Linux 2.6.x 内核中,调度性能的改进是其中最引人注目的一部分 [1]。NPTL(Native Posix Thread Library)[2] 使用内核的新特性重写了 Linux 的线程库,取代历史悠久而备受争议的 LinuxThreads [3] 成为 glibc 的首选线程库。
NPTL 的性能究竟如何?相对 LinuxThreads 又有哪些明显的改进?在对 NPTL 进行全面分析之前,本文针对这两种线程库,以及内核中 "内核可抢占"(Preemptible)和超线程(HyperThreading)[4] 等特性进行了全面的性能评测,结果表明 NPTL 绝对值得广大服务器系统期待和使用。
二、 Benchmark
1. 测试平台
进行本测试的硬件平台为浪潮 NF420R 服务器 [7],4 个 Hyperthreading-enabled Intel Xeon 2.2G 处理器,4G 内存。Linux 选择了 Slackware 9.0 发行版 [8],所使用的内核源码来自
www.kernel.org
。
2. 针对测试:LMBench
lmbench 是一个用于评价系统综合性能的多平台开源 benchmark [5],但其中没有对线程的支持。其中有两个测试进程性能的 benchmark:lat_proc 用于评测进程创建和终止的性能,lat_ctx 用于评测进程切换的开销。lmbench 拥有良好的 benchmark 结构,只需要修改具体的 Target 程序(如 lat_proc.c 和 lat_ctx.c),就可以借用 lmbench 的计时、统计系统得到我们关心的线程库性能的数据。
基于 lat_proc和lat_ctx 的算法,本文实现了 lat_thread和lat_thread_ctx 两个 benchmark。在 lat_thread 中,lat_proc 被改造成使用线程,用 pthread_create() 替代了 fork(),用 pthread_join() 替代 wait();在 lat_thread_ctx 中,沿用 lat_ctx 的评测算法(见 lat_ctx 手册页),将创建进程的过程改写为创建线程,仍然使用管道进行通信和同步。
lat_thread null
null 参数表示线程不进行任何实际操作,创建后即刻返回。
lat_thread_ctx -s #threads
size 参数与 lat_ctx 定义相同,可表示线程的大小(实际编程时为分配 K 数据;#threads 参数为线程数,即参与令牌传递的线程总数,相当于程序负载情况。
3. 综合测试:Volanomark
volanomark是一个纯java的benchmark,专门用于测试系统调度器和线程环境的综合性能[6],它建立一个模拟Client/Server方式的Java聊天室,通过获取每秒平均发送的消息数来评测宿主机综合性能(数值越大性能越好)。Volanomark测试与Java虚拟机平台相关,本文使用Sun Java SDK 1.4.2作为测试用Java平台,Volanomark版本2.5.0.9。
三、 测试结果
测试计划中将内核分为 2.4.26、2.6.6/ 支持内核抢占和 2.6.6/ 不支持内核抢占三类;通过配置内核以及 NF420R 的 BIOS 实现三类 SMP 规模:单处理机 (UP)、4CPU 的 SMP(SMP4)和打开超线程支持的虚拟 8CPU SMP(SMP8*)。内核配置和 SMP 规模的每一种组合都针对 LinuxThreads 和 NPTL 使用 lat_thread、lat_thread_ctx 和 volanomark 获取一组数据。由于 NPTL 无法在 2.4.x 内核上使用,该项数据空缺。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2