菊次郎的夏天 钢琴mp3:iostat详解

来源:百度文库 编辑:九乡新闻网 时间:2024/05/04 08:46:52

最近在做性能测试。发现集群中,有一个机器的io比较大。还不是太熟悉linux下的io如何评测。搜索到了如下的文章,挺好的,记录一下,分析io的一个不错的方法。

 

 

# iostat -x 1 10
Linux 2.6.18-92.el5xen    02/03/2009

avg-cpu: %user   %nice %system %iowait %steal   %idle
           1.10    0.00    4.82   39.54    0.07   54.46

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await svctm %util
sda               0.00     3.50 0.40 2.50     5.60    48.00    18.48     0.00    0.97   0.97   0.28
sdb               0.00     0.00 0.00 0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdc               0.00     0.00 0.00 0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdd               0.00     0.00 0.00 0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sde               0.00     0.10 0.30 0.20     2.40     2.40     9.60     0.00    1.60   1.60   0.08
sdf              17.40     0.50 102.00 0.20 12095.20     5.60   118.40     0.70    6.81   2.09 21.36
sdg             232.40     1.90 379.70 0.50 76451.20    19.20   201.13     4.94   13.78   2.45 93.16

rrqm/s:   每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s:           每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s:         每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s:    每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s:     每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。(需要计算)
wkB/s:    每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz:平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await:    平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util:     一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘
可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。


别人一个不错的例子.(I/O 系统 vs. 超市排队)

举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能 5 分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。

我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间。

下面是别人写的这个参数输出的分析

# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。

平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个 I/O 请求却需要等上 78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。

每秒发出的 I/O 请求很多 (约 29 个),平均队列却不长 (只有 2 个 左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的。

一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了。

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8,表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有 bug,avgqu-sz 值应为 2.23,而不是 22.35。

iostat详解

报告中央处理器(CPU)的统计信息,整个系统、适配器、tty 设备、磁盘以及 CD-ROM 的异步输入/输出(AIO)和输入/输出统计信息。
语法
iostat[ -a ] [ -l ] [ -s ] [-t ] [ -T ] [ -z ] [ { -A [ -P ] [ -q | -Q ] } |{ -d |-D [-R ] }[ -m ] [ Drives ... ] [ Interval] [ Count ]
描述
iostat 命令用来监视系统输入/输出设备负载,这通过观察与它们的平均传送速率相关的物理磁盘的活动时间来实现。iostat 命令生成的报告可以用来更改系统配置来更好地平衡物理磁盘和适配器之间的输入/输出负载。
每次运行 iostat 命令时,就报告所有的统计信息。报告由 tty and CPU 标题行以及接下来的 tty 或 异步 I/O 和 CPU 统计信息行组成。在多处理器系统上,CPU 统计信息是系统范围计算的,是所有处理器的平均值。
带有系统中当前活动的 CPU 数量和活动的磁盘数量的眉行显示在输出结果的开始部分。如果指定 -s 标志,则显示系统眉行,接下来的一行是整个系统的统计信息。系统主机名显示在系统眉行中。
如果指定 -a 标志,就会显示一个适配器头行,随后是一行适配器的统计信息。这后面将回有一个磁盘头行和连接到适配器的所有磁盘/CD-ROM 的统计信息。为所有与系统连接的磁盘适配器生成这种报告。
显示一个磁盘头行,随后是一行配置的磁盘的统计信息。如果指定 PhysicalVolume 参数,则只显示那些指定的名称。
如果指定 PhysicalVolume 参数,则可以指定一个或者更多的字母或者字母数字的物理卷。如果指定 PhysicalVolume参数,就会显示 tty 和 CPU报告并且磁盘报告包含指定驱动器的统计信息。如果没有发现指定逻辑驱动器名,则报告将列出指定的名称并且显示没有找到驱动器的消息。如果没有指定逻辑驱动器名,报告则包含所有已配置的磁盘和 CD-ROM 的统计信息。如果系统上没有配置驱动器,则不生成磁盘报告。PhysicalVolume参数中的第一个字符不能为数字型。
Interval 参数指定了在每个报告之间的以秒计算的时间量。如果没有指定 Interval参数,iostat 命令将生成一个包含统计信息的报告,该统计信息是在系统启动(引导)时间里生成的。 Count 参数可被指定来连接Interval 参数。如果指定了 Count 参数,它的记数值就确定在 Interval 秒间生成的报告数。如果指定了 Interval参数但没有指定 Count 参数,iostat 命令就会不断生成报告。
iostat命令用来确定一个物理卷是否正在形成一个性能瓶颈,以及是否有可能改善这种情况。物理卷的 %使用率字段表明了文件活动在驱动器中分布多均匀。物理卷的高 % 使用率是表明也许存在这个资源的争用很好的征兆。由于 CPU使用率的统计信息同样适用于 iostat 报告,CPU 在 I/O 等待队列中的时间的百分比可以在同一时间确定。如果 I/O等待时间是有效数字并且磁盘使用率不是在卷上均匀分布,则就要考虑在驱动器上分布数据。
从 AIX 5.3 开始,iostat 命令报告在 微分区 环境中所消耗的物理处理器数量(physc)和所消耗的授权百分比(% entc)。这些度量值只在 微分区 环境上显示。
注:
在为 iostat 命令维护磁盘 I/O 历史中,消耗一部分系统资源。使用 sysconfig子例程,或者系统管理接口工具(SMIT)来停止历史记录帐户。当 iostat 命令正为 Count 迭代运行时,并且如果系统配置中有影响iostat 命令输出的更改,则它会显示关于配置更改的警告消息。显示更新后的系统配置信息和标题后,它接着继续进行输出。
报告
iostat 命令生成四种类型的报告,tty 和 CPU 使用率报告、磁盘使用率报告、系统吞吐量报告和适配器吞吐量报告。
tty 和 CPU 使用率报告
由 iostat 命令生成的第一份报告是 tty 和 CPU 使用率报告。对于多处理器系统,CPU 值是所有处理器的总平均。同时,I/O 等待状态是系统级定义的,而不是每个处理器。报告有以下格式:
栏 描述
tin 显示了系统为所有 tty 读取的字符总数。
tout 显示了系统为所有 tty 写入的字符总数。
% user 显示了在用户级(应用程序)执行时生成的 CPU 使用率百分比。
% sys 显示了在系统级(内核)执行时生成的 CPU 使用率百分比。
% idle 显示了在 CPU 空闲并且系统没有未完成的磁盘 I/O 请求时的时间百分比。
% iowait 显示了 CPU 空闲期间系统有未完成的磁盘 I/O 请求时的时间百分比。
physc 消耗的物理处理器的数量,仅当分区与共享处理器运行时显示。
% entc 消耗的标题容量的百分比,仅当分区与共享处理器运行时显示。
每过一定时间间隔,内核就更新这条信息(一般每秒六十次)。tty 报告提供了从系统中所有终端的收到的每秒字符总数,以及和每秒输出到系统所有终端的字符的总数。
用来计算 CPU 磁盘 I/O 等待时间的方法
操作系统 V4.3.3 和后来的版本包含用来估算 CPU 在磁盘 I/O(wio 时间)等待上的所花时间的百分比的增强方法。用在 AIX4.3.2 和操作系统的早期版本上的方法在一定条件下,能够给出 SMP 上的 wio 时间的一个放大的视图。wio 时间是根据命令sar(%wio)、 vmstat(wa)和 iostat(% iowait)报告出来的。
在 AIX 4.3.2中和早期版本中使用的方法如下:在每个处理器(每处理器一秒一百次)的每个时钟中断上,将确定四个类别(usr/sys/wio/idle)中的哪一个放置在最后的 10ms 内。如果在时钟中断的时刻 CPU 以 usr 模式中处于忙状态,则 usr获得这个时间计点并归于此类。如果在时钟中断时刻 CPU 以内核模式中处于忙状态,则 sys 类别将获得该计时点。如果 CPU不处于忙状态,将检查是否在进行任何磁盘 I/O。如果在进行任何磁盘 I/O,则 wio 类别将增加。如果磁盘在进行 I/O 操作并且 CPU不忙,则 idle 类别将获取计时点。wio 时间的放大视图是由于所有空闲 CPU 被归为 wio 而不管在 I/O上等待的线程数所导致。例如,仅有一个线程执行 I/O 的系统可以报告超过 90% 的 wio 时间而不管其 CPU 数。
在AIX 4.3.3 中和后继版本中使用的方法如下:如果在那个 CPU 上启动一个未完成的 I/O,则操作系统 V4.3.3中的更改仅把一个空闲 CPU 标为 wio。当只有少数线程正在执行 I/O 否则系统就空闲的情况下,这种方法可以报告更少的 wio时间。例如,一个有四个 CPU 且只有一个线程执行 I/O 的系统将报告一个最大值是 25% 的 wio 时间。一个有 12 个 CPU且仅有一个线程执行 I/O 的系统将报告一个最大值为 8% 的 wio 时间。 NFS 客户机通过 VMM 读/写,并且为了完成一个 I/O而在 vmm 等待中用的时间现在将被报告为 I/O 等待时间。
磁盘使用率报告
由 iostat 命令生成的第二个报告是磁盘使用率报告。磁盘报告提供了在每个物理磁盘基础上的统计信息。缺省报告有与以下类似的格式:
% tm_act 表示物理磁盘处于活动状态的时间百分比(驱动器的带宽使用率)。
Kbps 表示以 KB 每秒为单位的传输(读或写)到驱动器的数据量。
tps 表示每秒钟输出到物理磁盘的传输次数。一次传输就是一个对物理磁盘的 I/O 请求。多个逻辑请求可被并为对磁盘的一个单一 I/O 请求。传输具有不确定的大小。
Kb_read 读取的 KB 总数。
Kb_wrtn 写入的 KB 总数。
如果指定了 -D 标志,则报告有以下度量值:
与磁盘传送(xfer)有关的度量值:
% tm_act 表示物理磁盘处于活动状态的时间百分比(驱动器的带宽使用率)。
bps 表示每秒传输(读或写)到驱动器的数据量。使用不同的后缀来代表传送单位。缺省单位是字节/秒。
tps 表示每秒钟输出到物理磁盘的传输次数。一次传输就是一个对物理磁盘的 I/O 请求。多个逻辑请求可被并为对磁盘的一个单一 I/O 请求。传输具有不确定的大小。
bread 表示每秒从驱动器上读取的数据量。使用不同的后缀来代表传送单位。缺省单位是字节/秒。
bwrtn 表示每秒写入到驱动器的数据量。使用不同的后缀来代表传送单位。缺省单位是字节/秒。
磁盘读取服务度量值(读取):
rps 表示每秒读取传输的数量。
avgserv 表示每次读取传输的平均服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
minserv 表示最少的读取服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxserv 表示最多的读取服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
timeouts 表示每秒读取超时的数量。
fails 表示每秒失败的读取请求的数量。
磁盘写入服务度量值(写入):
wps 表示每秒写入传输的数量。
avgserv 表示每次写入传输的平均服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
minserv 表示最少的写入服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxserv 表示最多的写入服务时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
timeouts 表示每秒写入超时的数量。
fails 表示每秒失败的写入请求的数量。
磁盘等待队列服务度量值(队列):
avgtime 表示传输请求在等待队列中所花的平均时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
mintime 表示传输请求在等待队列中所花的最短时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxtime 表示传输请求在等待队列中所花的最长时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
avgwqsz 表示等待队列的平均大小。
avgsqsz 表示服务队列的平均大小。
sqfull 表示每秒内服务队列变满(即,磁盘不再接受任何服务请求)的次数。
代表不同说明单元的后缀图注
后缀 描述
K 1000 字节
M 1 000 000 字节(如果以 xfer 度量值显示)。分钟(如果以读取/写入/等待服务度量值显示)。
G 1 000 000 000 字节。
T 1 000 000 000 000 字节。
S 秒。
H 小时。
注:
对于不支持服务时间度量值的驱动器,将不显示读取、写入和等候队列服务度量值。
CD-ROM 设备的统计信息也要报告。
系统吞吐量报告
如果指定 -s 标志将生成这个报告。这份报告提供了整个系统的统计信息。这份报告有以下格式:
Kbps 表示了每秒以 KB 为单位的传输(读或写)到整个系统的数据量。
tps 表示每秒传输到整个系统的传输次数。
Kb_read 从整个系统中读取的 KB 总数。
Kb_wrtn 写到整个系统的 KB 总数。
适配器吞吐量报告
如果指定 -a 标志将生成该报告。这份报告提供了以每个适配器(包括物理适配器和虚拟适配器)为基础的统计信息。该报告对于物理适配器报告具有以下格式:
Kbps 表示每秒钟以 KB 为单位的传输到(读或写)到适配器的数据量。
tps 表示每秒钟输出到适配器的传输次数。
Kb_read 从适配器读取的 KB 总数。
Kb_wrtn 写到适配器的 KB 总数。
虚拟适配器的缺省吞吐量报告有以下格式:
Kbps 表示每秒钟以 KB 为单位的传输到(读或写)到适配器的数据量。
tps 表示每秒钟输出到适配器的传输次数。
bkread 每秒从托管服务器接收至该适配器的块数。
bkwrtn 每秒从该适配器发送至托管服务器的块数。
partition-id 托管服务器的分区标识,它为该适配器发送的请求提供服务。
虚拟适配器的扩展吞吐量报告(-D 选项)有以下格式:
与传送(xfer:)有关的度量值
Kbps 表示每秒钟以 KB 为单位的传输到(读或写)到适配器的数据量。
tps 表示每秒钟输出到适配器的传输次数。
bkread 每秒从托管服务器接收至该适配器的块数。
bkwrtn 每秒从该适配器发送至托管服务器的块数。
partition-id 托管服务器的分区标识,它为该适配器发送的请求提供服务。
适配器读取服务度量值(读取:)
rps 表示每秒读取请求的数量。
avgserv 表示为已发送的读取请求从托管服务器上接收响应的平均时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
minserv 表示为已发送的读取请求从托管服务器上接收响应的最短时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxserv 表示为已发送的读取请求从托管服务器上接收响应的最长时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
适配器写入服务度量值(写入:)
wps 表示每秒写入请求的数量。
avgserv 表示为已发送的写入请求从托管服务器上接收响应的平均时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
minserv 表示为已发送的写入请求从托管服务器上接收响应的最短时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxserv 表示为已发送的写入请求从托管服务器上接收响应的最长时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
适配器等待队列度量值(队列:)
avgtime 表示传输请求在等待队列中所花的平均时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
mintime 表示传输请求在等待队列中所花的最短时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
maxtime 表示传输请求在等待队列中所花的最长时间。使用不同的后缀来代表时间单位。缺省单位是毫秒。
avgwqsz 表示等待队列的平均大小。
avgsqsz 表示服务队列的平均大小。
sqfull 表示每秒内服务队列变满(即,托管服务器不再接受任何服务请求)的次数。
代表不同说明单元的后缀图注
后缀 描述
K 1000 字节。
M 1 000 000 字节(如果以 xfer 度量值显示)。分钟(如果以读取/写入/等待服务度量值显示)。
G 1 000 000 000 字节。
T 1 000 000 000 000 字节。
S 秒。
H 小时。
异步 I/O 报告
异步 I/O 报告有以下列标题:
avgc 指定时间间隔的每秒平均全局 AIO 请求计数。
avfc 指定时间间隔的每秒平均快速路径请求计数。
maxgc 上一次访存这个值以来的最大全局 AIO 请求计数。
maxfc 上一次访存这个值以来的最大快速路径请求计数。
maxreqs 所允许的最大 AIO 请求数。
磁盘输入/输出历史记录
为了提高性能,已经禁用了磁盘输入/输出统计信息的收集。要启用该数据的集合,请输入:

chdev -l sys0 -a iostat=true
要显示当前设置,请输入:

lsattr -E -l sys0 -a iostat
如果禁用了磁盘输入/输出历史记录的收集,并且在不带时间间隔的情况下调用了 iostat,则 iostat 输出将显示消息自引导以来的磁盘历史记录不可用,而不是磁盘统计信息。
标志
-a 指定适配器吞吐量报告。
-A 显示指定时间间隔和计数的 AIO 统计信息。
-d 只指定驱动器报告。
-D 只指定扩展驱动器报告。
-l 对长列表方式显示输出。缺省列宽是 80。
-m 指定路径的统计信息。
-P 与 -A 选项相同,使用 POSIX AIO 调用获取的数据除外。
-q 指定 AIO 队列和它们的请求计数。
-Q 显示所有安装的文件系统和相关的队列数以及它们请求计数的列表。
-R 指定在每个时间间隔都应复位 min* 和 max* 值。缺省情况下将仅在 iostat 启动时执行一次复位。
-s 指定系统吞吐量报告。
-t 只指定 tty/cpu 报告。
-T 指定时间戳记。
-z 复位磁盘输入/输出统计信息。只有 root 用户才可以使用此选项。
注:
-q 或 -Q 只能与 -A 一起指定。
-a 和 -s 也可以与 -A 一起指定,但在指定了-q 或 -Q 时不能与 -A 一起指定。
-t 和 -d 不能同时指定。
-t 和 -D 不能同时指定。
-d 和 -D 不能同时指定。
-R 只能和 -D 一起指定。
示例
要为所有 tty、CPU 和磁盘显示引导后的单一历史记录报告,请输入:
iostat
要为逻辑名是 disk1 的磁盘显示一个以两秒为时间间隔的持续磁盘报告,请输入:
iostat -d disk1 2
要为逻辑名是 disk1 的磁盘显示以两秒为时间间隔的六个报告,请输入:
iostat disk1 2 6
要为所有磁盘显示以两秒为时间间隔的六个报告,请输入:
iostat -d 2 6
要为三个名称分别为 disk1、disk2、disk3 的磁盘显示以两秒为时间间隔的六个报告,请输入:
iostat disk1 disk2 disk3 2 6
要打印系统引导以来的系统吞吐量报告,请输入:

iostat -s
要打印以五秒为时间间隔的适配器吞吐量报告,请输入:
iostat -a 5
要打印以二十秒为时间间隔的十个系统和适配器吞吐量报告,且仅带有 tty 和 CPU 报告(没有磁盘报告),请输入:

iostat -sat 20 10
要打印带有 hdisk0 和 hdisk7 的磁盘使用率报告的系统和适配器吞吐量报告(每 30 秒一次),请输入:
iostat -sad hdisk0 hdisk7 30
要显示 iostat 输出的每行的下一行的时间戳记,请输入:
iostat -T 60
要显示关于 AIO 的以两秒为时间间隔的六个报告,请输入:
iostat -A 2 6
要显示自引导以来与所有已安装的文件系统相关的队列的 AIO 统计信息,请输入:
iostat -A -Q
要显示所有磁盘的扩展驱动器报告,请输入:
iostat -D
要显示某个特定磁盘的扩展驱动器报告,请输入:
iostat –D hdisk0
要复位磁盘输入/输出统计信息,请输入:
iostat –z
文件
/usr/bin/iostat 包含 iostat 命令。

 

查看aix下物理内存

AIX中如何查看内存容量

2008年06月23日 星期一 21:38

 

#bootinfo -r

查看物理内存

lsattr -El mem0

lsattr -El sys0 -a realmem

使用命令# lsdev -Cc memory

查看配置的物理内存设备,下面为其输出示例:

mem0 Available 00-00 Memory

L2cache0 Available 00-00 L2 Cache

再使用命令# lsattr -El mem0

输出如下

size 512 Total amount of physical memory in Mbytes False

goodsize 512 Amount of usable physical memory in Mbytes False

此例说明机器的物理内存为512MB。如果前面lsdev的输出中有设备名 mem1,则使用同样的命令查看其对应的大小并依此类推。

prtconf就可以查看系统所有的信息 cpu 内存 硬盘等..

svmon -G

root@m2a/etc>svmon -G

size inuse free pin virtual

memory 4194304 1088794 3105510 274650 690272

pg space 2097152 3775

work pers clnt lpage

pin 274650 0 0 0

in use 690290 257951 140553 0

root@m2a/etc>

其中: size表示真实的物理内存的大小,单位是4k

 

iostat 输出解析
1. /proc/partitions
对于kernel 2.4, iostat 的数据的主要来源是 /proc/partitions,而对于kernel 2.6, 数据主要来自/proc/diskstats或/sys/block/[block-device-name]/stat。
先看看 /proc/partitions 中有些什么。
# cat /proc/partitions
major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq
3 0 19535040 hda 12524 31127 344371 344360 12941 25534 308434 1097290 -1 15800720 28214662
3 1 7172991 hda1 13 71 168 140 0 0 0 0 0 140 140
3 2 1 hda2 0 0 0 0 0 0 0 0 0 0 0
3 5 5116671 hda5 100 477 665 620 1 1 2 30 0 610 650
3 6 265041 hda6 518 92 4616 2770 257 3375 29056 143880 0 46520 146650
3 7 6980211 hda7 11889 30475 338890 340740 12683 22158 279376 953380 0 509350 1294120
major: 主设备号。3 代表 hda。
minor: 次设备号。7 代表 No.7 分区。
#blocks: 设备总块数 (1024 bytes/block)。19535040*1024 => 20003880960(bytes) ~2G
name: 设备名称。如 hda7。
rio: 完成的读 I/O 设备总次数。指真正向 I/O 设备发起并完成的读操作数目,
也就是那些放到 I/O 队列中的读请求。注意非常多进程发起的读操作
(read())非常可能会和其他的操作进行 merge,不一定每个 read() 调用
都引起一个 I/O 请求。
rmerge: 进行了 merge 的读操作数目。
rsect: 读扇区总数 (512 bytes/sector)
ruse: 从进入读队列到读操作完成的时间累积 (毫秒)。上面的例子显示从开机
开始,读 hda7 操作共用了约340秒。
wio: 完成的写 I/O 设备总次数。
wmerge: 进行了 merge 的写操作数目。
wsect: 写扇区总数
wuse: 从进入写队列到写操作完成的时间累积 (毫秒)
running: 已进入 I/O 请求队列,等待进行设备操作的请求总数。上面的例子显
示 hda7 上的请求队列长度为 0。
use: 扣除重叠等待时间的净等待时间 (毫秒)。一般比 (ruse+wuse) 要小。比
如 5 个读请求同时等待了 1 毫秒,那么 ruse值为5ms, 而 use值为
1ms。use 也能理解为I/O队列处于不为空状态的总时间。hda7 的I/O
队列非空时间为 509 秒,约合8分半钟。
aveq: 在队列中总的等待时间累积 (毫秒) (约等于ruse+wuse)。为什么是“约等于”而不是等于呢?让我们看看aveq, ruse, wuse的计算方式,这些量一般是在I/O完成后进行更新的:
   aveq += in-flight * (now - disk->stamp);
   ruse += jiffies - req->start_time; // 如果是读操作的话
   wuse += jiffies - req->start_time;   // 如果是写操作的话
注 意aveq计算中的in-flight,这是当前还在队列中的I/O请求数目。这些I/O还没有完成,所以不能计算到ruse或wuse中。理论上,只有 在I/O全部完成后,aveq才会等于ruse+wuse。举一个例子,假设初始时队列中有三个读请求,每个请求需要1秒钟完成。在1.5秒这一时刻, aveq和ruse各是多少呢?
   ruse = 1 // 因为此时只有一个请求完成
   aveq = 3*1 + 2*0.5 = 4 // 因为第二个请求刚发出0.5秒钟,另更有一个请求在队列中呢。
                                  // 这样第一秒钟时刻有3个in-flight,而1.5秒时刻有2个in-flight.
如果三个请求全部完成后,ruse才和aveq相等:
   ruse = 1 + 2 + 3 = 6
   aveq = 1 + 2 + 3 = 6
周详说明请参考 linux/drivers/block/ll_rw_blk.c中的end_that_request_last()和disk_round_stats()函数。
2. iostat 结果解析
# iostat -x
Linux 2.4.21-9.30AX (localhost) 2004年07月14日
avg-cpu: %user %nice %sys %idle
3.85 0.00 0.95 95.20
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/hda 1.70 1.70 0.82 0.82 19.88 20.22 9.94 10.11 24.50 11.83 57.81 610.76 99.96
/dev/hda1 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 12.92 0.00 10.77 10.77 0.00
/dev/hda5 0.02 0.00 0.00 0.00 0.03 0.00 0.02 0.00 6.60 0.00 6.44 6.04 0.00
/dev/hda6 0.01 0.38 0.05 0.03 0.43 3.25 0.21 1.62 46.90 0.15 193.96 52.25 0.41
/dev/hda7 1.66 1.33 0.76 0.79 19.41 16.97 9.70 8.49 23.44 0.79 51.13 19.79 3.07
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。即 delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作,或说一秒中有多少时间 I/O 队列是非空的。
即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已满负荷,该磁盘
可能存在瓶颈。
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),
svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多
也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 及
I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await,说明
I/O 几乎没有等待时间;如果 await 远大于 svctm,说明 I/O 队列太长,应用
得到的响应时间变慢,如果响应时间超过了用户能容许的范围,这时能考虑
更换更快的磁盘,调整内核 elevator 算法,优化应用,或升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是
按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。
3. I/O 系统 vs. 超市排队
举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当
是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人
购买的东西多少,如果前面有个采购了一星期食品的大妈,那么能考虑换个队
排了。更有就是收银员的速度了,如果碰上了连钱都点不清晰的新手,那就有的
等了。另外,时机也非常重要,可能 5 分钟前还人满为患的收款台,目前已是人
去楼空,这时候交款可是非常爽啊,当然,前提是那过去的 5 分钟里所做的事情
比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。
I/O 系统也和超市排队有非常多类似之处:
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
我们能根据这些数据分析出 I/O 请求的模式,及 I/O 的速度和响应时间。
4. 一个例子
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: delta(io)/s = r/s +
w/s = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。
平均每次设备 I/O 操作只需要 5ms 就能完成,但每个 I/O 请求却需要等上
78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是
同时发出的,那么平均等待时间能这样计算:
平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数
应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms,和
iostat 给出的 78ms 的平均等待时间非常接近。这反过来表明 I/O 是同时发起的。
每秒发出的 I/O 请求非常多 (约 29 个),平均队列却不长 (只有 2 个 左右),
这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的。
一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里
I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =
78.21 * delta(io)/s = 78.21*28.57 = 2232.8,表明每秒内的I/O请求总共需
要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23,而 iostat
给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有
bug,avgqu-sz 值应为 2.23,而不是 22.35。
5. iostat 的 bug 修正
iostat.c 中是这样计算avgqu-sz的:
((double) current.aveq) / itv
aveq 的单位是毫秒,而 itv 是两次采样之间的间隔,单位是 jiffies。必须换
算成同样单位才能相除,所以正确的算法是:
((double) current.aveq) / itv * HZ / 1000
这样,上面 iostat 中输出的 avgqu-sz 值应为 2.23,而不是 22.3。
另外,util值的计算中做了 HZ 值的假设,不是非常好,也需要修改。
--- sysstat-4.0.7/iostat.c.orig 2004-07-15 13:31:27.000000000 +0800
+++ sysstat-4.0.7/iostat.c 2004-07-15 13:37:34.000000000 +0800
@@ -370,7 +370,7 @@
nr_ios = current.rd_ios + current.wr_ios;
tput = nr_ios * HZ / itv;
- util = ((double) current.ticks) / itv;
+ util = ((double) current.ticks) / itv * HZ / 1000;
/* current.ticks (ms), itv (jiffies) */
svctm = tput ? util / tput : 0.0;
/* kernel gives ticks already in milliseconds for all platforms -> no need for further scaling */
@@ -387,12 +387,12 @@
((double) current.rd_sectors) / itv * HZ, ((double) current.wr_sectors) / itv * HZ,
((double) current.rd_sectors) / itv * HZ / 2, ((double) current.wr_sectors) / itv * HZ / 2,
arqsz,
- ((double) current.aveq) / itv,
+ ((double) current.aveq) / itv * HZ / 1000, /* aveq is in ms */
await,
/* again: ticks in milliseconds */
- svctm * 100.0,
+ svctm,
/* NB: the ticks output in current sard patches is biased to output 1000 ticks per second */
- util * 10.0);
+ util * 100.0);
}
}
}
一会儿 jiffies, 一会儿 ms,看来 iostat 的作者也被搞晕菜了。
这个问题在 systat 4.1.6 中得到了修正:
* The average I/O requests queue length as displayed by iostat -x was
wrongly calculated. This is now fixed.
但 Redhat 的 sysstat 版本有些太过时了 (4.0.7)。