2013-04-14 17:58:34 lingzhi007 阅读数 26

转 http://wangchengtai.blog.hexun.com/39388948_d.html

 

 

Unix/Linux 磁盘 I/O 性能监控命令

磁盘 I/O 性能监控指标和调优方法

在介绍磁盘 I/O 监控命令前,我们需要了解磁盘 I/O 性能监控的指标,以及每个指标的所揭示的磁盘某方面的性能。磁盘 I/O 性能监控的指标主要包括:

指标 1:每秒 I/O 数(IOPS 或 tps)

对于磁盘来说,一次磁盘的连续读或者连续写称为一次磁盘 I/O, 磁盘的 IOPS 就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时,该指标有重要参考意义。

指标 2:吞吐量(Throughput)

指硬盘传输数据流的速度,传输数据为读出数据和写入数据的和。其单位一般为 Kbps, MB/s 等。当传输大块不连续数据的数据,该指标有重要参考作用。

指标 3:平均 I/O 数据尺寸

平均 I/O 数据尺寸为吞吐量除以 I/O 数目,该指标对揭示磁盘使用模式有重要意义。一般来说,如果平均 I/O 数据尺寸小于 32K,可认为磁盘使用模式以随机存取为主;如果平均每次 I/O 数据尺寸大于 32K,可认为磁盘使用模式以顺序存取为主。

指标 4:磁盘活动时间百分比(Utilization)

磁盘处于活动时间的百分比,即磁盘利用率,磁盘在数据传输和处理命令(如寻道)处于活动状态。磁盘利用率与资源争用程度成正比,与性能成反比。也就是说磁盘利用率越高,资源争用就越严重,性能也就越差,响应时间就越长。一般来说,如果磁盘利用率超过 70%,应用进程将花费较长的时间等待 I/O 完成,因为绝大多数进程在等待过程中将被阻塞或休眠。

指标 5:服务时间(Service Time)

指磁盘读或写操作执行的时间,包括寻道,旋转时延,和数据传输等时间。其大小一般和磁盘性能有关,CPU/ 内存的负荷也会对其有影响,请求过多也会间接导致服务时间的增加。如果该值持续超过 20ms,一般可考虑会对上层应用产生影响。

指标 6:I/O 等待队列长度(Queue Length)

指待处理的 I/O 请求的数目,如果 I/O 请求压力持续超出磁盘处理能力,该值将增加。如果单块磁盘的队列长度持续超过 2,一般认为该磁盘存在 I/O 性能问题。需要注意的是,如果该磁盘为磁盘阵列虚拟的逻辑驱动器,需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目,以获得平均单块硬盘的 I/O 等待队列长度。

指标 7:等待时间(Wait Time)

指磁盘读或写操作等待执行的时间,即在队列中排队的时间。如果 I/O 请求持续超出磁盘处理能力,意味着来不及处理的 I/O 请求不得不在队列中等待较长时间。

 

通过监控以上指标,并将这些指标数值与历史数据,经验数据以及磁盘标称值对比,必要时结合 CPU、内存、交换分区的使用状况,不难发现磁盘 I/O 潜在或已经出现的问题。但如果避免和解决这些问题呢?这就需要利用到磁盘 I/O 性能优化方面的知识和技术。限于本文主题和篇幅,仅列出一些常用的优化方法供读者参考:

1. 调整数据布局,尽量将 I/O 请求较合理的分配到所有物理磁盘中。
2. 对于 RAID 磁盘阵列,尽量使应用程序 I/O 等于条带尺寸或者为条带尺寸的倍数。并选取合适的 RAID 方式,如 RAID10,RAID5。
3. 增大磁盘驱动程序的队列深度,但不要超过磁盘的处理能力,否则,部分 I/O 请求会因为丢失而重新发出,这将降低性能。
4. 应用缓存技术减少应用存取磁盘的次数,缓存技术可应用在文件系统级别或者应用程序级别。
5. 由于多数数据库中已包括经优化后的缓存技术,数据库 I/O 宜直接存取原始磁盘分区(raw partition)或者利用绕过文件系统缓存的 DIO 技术(direct IO)
6. 利用内存读写带宽远比直接磁盘 I/O 操作性能优越的特点,将频繁访问的文件或数据置于内存中。
磁盘 I/O 性能监控命令简介

Unix/Linux 提供了两个非常有用的用于磁盘 I/O 性能监控的命令:iostat 和 sar。

iostat 命令主要通过观察物理磁盘的活动时间以及他们的平均传输速度,监控系统输入 / 输出设备负载。根据 iostat 命令产生的报告,用户可确定一个系统配置是否平衡,并据此在物理磁盘与适配器之间更好地平衡输入 / 输出负载。iostat 工具的主要目的是通过监控磁盘的利用率,而探测到系统中的 I/O 瓶颈。不同操作系统命令格式输出格式略有不同,管理员可以通过查看用户手册来确定它的用法。

sar 命令报告 CPU 的使用情况,I/O 以及其它系统行为。sar 命令可以收集,报告以及保存系统行为信息。以这种方式收集到的数据对于确定系统的时间周期特征和决定峰值使用时间是很有用的。但要注意的是,sar 命令自己运行时会产生相当数量的读写,因此最好在没有工作量的情况下运行 sar 统计,看看 sar 对总的统计数字有多大的影响。

AIX 环境下,iostat 和 sar 位于文件集 bos.acct 中,是基本系统 (Base Operating System) 的一部分,在缺省安装情况下无需进行任何配置或任何额外包安装。

Linux 环境下,iostat 和 sar 包含在 sysstat 包中。sysstat 是 Linux 系统中的常用工具包。不同的 Linux 系统或不同的硬件平台,安装包名字和具体命令可能会有微小差异。清单1为一个在 RHEL5.3 上安装 sysstat 包的例子。

iostat -d -x 10 3

Device:  rrqm/s  wrqm/s  r/s  w/s  rsec/s  wsec/s avgrq-sz avgqu-sz  await  svctm  %util
主要字段含义如下:

r/s 每秒读操作数。

w/s 每秒写操作数。

rsec/s 每秒从设备读取的扇区数量。

wsec/s 每秒向设备写入的扇区数量。

avgrq-sz I/O 请求的平均扇区数。

avgqu-sz I/O 请求的平均队列长度。

await I/O 请求的平均等待时间,单位为毫秒。

svctm I/O 请求的平均服务时间,单位为毫秒。

%util 处理 I/O 请求所占用的时间的百分比,即设备利用率。
#sar -pd 10 3
输出的主要字段含义如下:

DEV 正在监视的块设备

tps 每秒钟物理设备的 I/O 传输总量

rd_sec/s 每秒从设备读取的扇区数量

wr_sec/s 每秒向设备写入的扇区数量

avgrq-sz I/O 请求的平均扇区数

avgqu-sz I/O 请求的平均队列长度

await I/O 请求的平均等待时间,单位为毫秒

svctm I/O 请求的平均服务时间,单位为毫秒

%util I/O 请求所占用的时间的百分比,即设备利用率
Unix/Linux 系统磁盘 I/O 性能监控自动化脚本示例

前文介绍了 AIX 与 Linux 磁盘 I/O 监控的手段,本节将结合实例介绍磁盘 I/O 监控的自动化脚本的设计和实现。

设计思路

1 . 监控指标

前文介绍了多个监控指标,比如吞吐量,每秒 I/O 数,平均单次 I/O 响应时间,磁盘利用率等,用户可以根据自身系统和应用的特点选取监控指标。下文将以磁盘利用率为例进行监控脚本的设计。

2 .监控手段

对于 AIX, 命令“iostat -d”的输出字段“% tm_act”反映磁盘利用率;对于 Linux, 命令“iostat -d -x”的输出字段“%util”反映磁盘利用率。监控的频次可以通过“iostat”命令本身的参数指定。

3. 告警机制

一般来说,如果磁盘使用率长时间达到 75% 或 80%, 通常会视为磁盘较忙,一般需进行调整磁盘布局,调整应用使用分配等管理活动,如果磁盘使用率偶尔较高,只需要继续监视即可。因此告警既不能对于偶发现象频繁告警,也不能放过持续时间较长的现象,本例的告警机制设定为“在一定时间间隔内的一定比例的监控记录超出设定的磁盘利用率门限值即告警”

4 .日志

要保留磁盘 I/O,分析活动,告警信息等原始信息,便于以后进行问题分析,定位。

磁盘 I/O 分析和告警自动脚本

结合上文设计思路,笔者开发了磁盘 I/O 分析和告警脚本 I/OAnalyzer.sh, 我们的脚本在 RHEL 5.3、SLES 11、AIX 5.3 和 AIX 6.1 上测试通过。

脚本 IOAnalyzer.sh 的第一部分先进行了初始化,检验并处理输入参数,对未输入的参数指定默认值。

清单 6. IOAnalyzer.sh 脚本初始化部分

01.#!/bin/sh
02. # ================================================================
03. # Script Name:  IOAnalyzer.sh
04. # Desciption:   To analyze output of 'iostat -d', send an alert to admin
05. #              if disk utilization counter reach defined threshold
06. # Date:         May 19, 2009
07. #================================================================
08. 
09.# -----------------------------------------------------------------
10. # Function definitions...                                定义函数
11. #----------------------------------------------------------------
12. 
13.function usage {
14. echo ""
15. echo "usage: IOAnalyzer.sh -i inIostatFile [ -l outLogFile ] \
16. [ -a outAlertFile ] [ -u dishUtil ] [ -r rateGEUtil ]"
17. echo ""
18. echo "For example: IOAnalyzer.sh -i /tmp/iostat.out -l /tmp/logFile \
19. -a /tmp/aletFile -u 80 -r 70"
20. echo "For AIX, please run 'iostat -d [ <interval> [ <count> ] \
21. to create inIostatFile"
22. echo "For Linux, please run 'iostat -d -x [ <interval> [ <count> ] \
23. to create inIostatFile"
24. exit 1
25. }
26. 
27.# ----------------------------------------------------------------
28. # Process command-line arguments                          命令行参数处理
29. # ----------------------------------------------------------------
30. while getopts :i:l:a:u:r: opt
31. do
32. case "$opt" in
33. i) inIostatFile="$OPTARG";;
34. l) outLogFile="$OPTARG";;
35. a) outAlertFile="$OPTARG";;
36. u) diskUtil="$OPTARG";;
37. r) rateGEUtil="$OPTARG";;
38. \?) usage;;
39. esac
40. done
41. 
42.#----------------------------------------------------------------
43. # Input validation                                       输入验证
44. #----------------------------------------------------------------
45. 
46.if [ ! -f "$inIostatFile" ]
47. then
48. echo "error: invalid Augument inIostatFile in OPTION -i "
49. usage
50. exit 1
51. fi
52. #---------------------------------------------------------------
53. 
54.# Set values, if unset                                   设置变量
55. # ----------------------------------------------------------------
56. 
57.outLogFile=${outLogFile:-${inIostatFile}.log}
58. outAlertFile=${outAlertFile:-${inIostatFile}.alert}
59. diskUtil=${diskUtil:-'80'}
60. rateGEUtil=${rateGEUtil:-'60'}

接下来, IOAnalyzer.sh 脚本查询日志,通过计算起止行的办法定位 IO 输出文件的待分析文本。

清单 7. IOAnalyzer.sh 脚本定位 I/O 输出文件待分析部分

01.# ----------------------------------------------------------------
02. # Identify the lines to be analyzed between StartLine and Endline
03. # 定位日志中待分析文本
04. 
05.# ----------------------------------------------------------------
06. 
07.if [ ! -f "$outLogFile" ] || [ ! tail -1 "$outLogFile"|grep 'ENDLINE']
08. then
09. StartLineNum=1;
10. else
11. CompletedLine=`tail -1 "$outLogFile" grep 'ENDLINE' | \
12. awk '{print $4}'|cut -d: -f2`
13. StartLineNum=`expr 1 + $CompletedLine`
14. fi
15. 
16.eval "sed -n '${StartLineNum},\$p' $inIostatFile" > ${inIostatFile}.tail
17. 
18.LineCount=`cat ${inIostatFile}.tail|wc -l|awk '{print $1}'`
19. EndLineNum=`expr $LineCount + $StartLineNum`

清单 7 中的脚本实现了按行分析上文定位的 iostat 输出,如果某行磁盘利用率小于先前定义的门限值,则在行尾标记“OK”,如果某行磁盘利用率大于等于先前定义的门限值,则在行尾标记“Alarm”。并且脚本中对于 AIX 和 Linux 输出格式和磁盘命名的不同作了相应处理。

清单 8. IOAnalyzer.sh 按行分析 iostat 输出

01.# ----------------------------------------------------------------
02. # Analyze 'iostat' output, append "Alarm" or "OK" at the end of each# line
03. 
04.# ----------------------------------------------------------------
05. OS=`uname`
06. case "$OS" in
07. AIX)
08. diskUtilLabel="% tm_act"
09. diskUtilCol=2
10. diskPrefix="hdisk"
11. ;;
12. Linux)
13. diskUtilLabel="%util"
14. diskUtilCol=14
15. diskPrefix="hd|sd"
16. ;;
17. *)      echo "not support $OS operating system!"
18. exit 1;
19. ;;
20. esac
21. 
22.eval "cat ${inIostatFile}.tail egrep '${diskPrefix}' \
23. awk '{if ( \$${diskUtilCol} * 100 < ${diskUtil} ) \
24. {\$20 = \"OK\"; print \$1\"\t\"\$${diskUtilCol}\"\t\"\$20 } \
25. else {\$20 = \"Alarm\"; print \$1\"\t\"\$${diskUtilCol}\"\t\"\$20 } }'" \
26. > ${outLogFile}.tmp

下文脚本给出一个告警触发的例子,如果过高的磁盘利用率计数占总分析行数的比率达到或超出预定的比率,脚本会给 root 用户发一封告警邮件。

清单 9. IOAnalyzer.sh 触发告警

01.# ----------------------------------------------------------------
02. # Send admin an alert if disk utilization counter reach defined
03. # threshold
04. 
05.# ----------------------------------------------------------------
06. Alert="NO"
07. for DISK in `cut -f1  ${outLogFile}.tmp | sort -u`
08. do
09. numAlarm=`cat ${outLogFile}.tmp | grep "^$DISK.*Alarm$" |wc -l`
10. numRecord=`cat ${outLogFile}.tmp | grep "^$DISK" |wc -l`
11. rateAlarm=`expr $numAlarm \* 100 / $numRecord`
12. if [ $rateAlarm -ge $rateGEUtil ];then
13. echo "DISK:${DISK}      TIME:`date +%Y%m%d%H%M`  \
14. RATE:${rateAlarm}      THRESHOLD:${rateGEUtil}" >> ${outAlertFile}.tmp
15. Alert="YES"
16. fi
17. done
18. if [ $Alert= "YES" ];then
19. cat ${outAlertFile}.tmp >> ${outAlertFile}
20. mail -s "DISK IO Alert"  root@localhost< ${outAlertFile}.tmp
21. fi

最后,脚本将分析活动归档,便于下次分析时定位起始行;另外,分析过程中产生的文件将被删除。

清单 10. IOAnalyzer.sh 记录分析活动日志和清除临时文件

01.#----------------------------------------------------------------
02. # Clearup temporary files and logging
03. # ----------------------------------------------------------------
04. 
05.echo "IOSTATFILE:${inIostatFile}        TIME:`date +%Y%m%d%H%M`  \
06. STARTLINE:${StartLineNum}       ENDLINE:${EndLineNum}   ALERT:${Alert}" \
07. 
08.>> ${outLogFile}
09. 
10.rm -f ${outLogFile}.tmp
11. rm -f ${outAlertFile}.tmp
12. rm -f ${inIostatFile}.tail
13. 
14.exit 0

脚本使用示例

以下为 IOAnalyzer.sh 脚本在 AIX 上使用示例

1 .后台执行 iostat, 并将输出重定向到文件中

清单 11. 后台执行 iostat

# nohup iostat -d 5 > /root/iostat.out &
(对于 Linux,运行 iostat -d – x 5 > /root/iostat.out &)

2 .编辑 crontab 文件,每 10 分钟运行一次 IOAnalyzer.sh 脚本,-u 70 –r 80,表示在距上次运行 IOAnalyzer.sh 至今产生的某磁盘的监控记录中的 80% 使用率达到或超过 70%,即发出告警。告警日志和分析日志可通过 IOAnalyzer.sh 的 –l –a 参数指定,本例保持默认值,即在 iostat 的输出文件所在目录产生 iostat.out.log 和 iostat.out.alert 文件。

清单 12. 编辑 crontab

# crontab – e
0,10,20,30,40,50 * * * * /root/IOAnalyzer.sh -i /root /iostat.out -u 70 \
-r 80>/tmp/iostat.out 2>&1

3 .用户收到告警邮件,需要进一步查询历史记录时,可查看日志文件

清单 13. 查看日志文件

# cat /root/iostat.out.log | more
IOSTATFILE: /root/iostat.out TIME:200905200255 STARTLINE:7220 ENDLINE:7580  ALARM:YES
IOSTATFILE: /root/iostat.out  TIME:200905200300  STARTLINE:7581 ENDLINE:7940 ALARM:YES
IOSTATFILE:/root/iostat.out TIME:200905200305  STARTLINE:7941 ENDLINE:8300 ALARM:YES

[AIXn01]> cat /root/iostat.out.alert | more
DISK:hdisk4     TIME:200905200250         RATE:84      THRESHOLD:70
DISK:hdisk5     TIME:200905200250         RATE:84      THRESHOLD:70
DISK:hdisk6     TIME:200905200250         RATE:84      THRESHOLD:70

2017-11-13 16:37:31 zhengfeilong0606 阅读数 2309

LINUX IO 总结

  磁盘通常是计算机最慢的子系统,也是最容易出现性能瓶颈的地方,因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作,比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的,就像1天和1分钟的差别一样。要监测 IO 性能,有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。

一.linux IO 中断

1.缺页中断

  内存和硬盘之间的 IO 是以页为单位来进行的,在 Linux 系统上1页的大小为 4K。
  Linux “内存” 包括物理内存和虚拟内存,虚拟内存(Virtual Memory)把计算机的内存空间扩展到硬盘,物理内存(RAM)和硬盘的一部分空间(SWAP)组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间.
  Linux 利用虚拟内存极大的扩展了程序地址空间,使得原来物理内存不能容下的程序也可以通过内存和硬盘之间的不断交换(把暂时不用的内存页交换到硬盘,把需要的内存页从硬盘读到内存)来赢得更多的内存,看起来就像物理内存被扩大了一样。当程序启动的时候,Linux 内核首先检查 CPU 的缓存和物理内存,如果数据已经在内存里就忽略,如果数据不在内存里就引起一个缺页中断(Page Fault),然后从硬盘读取缺页,并把缺页缓存到物理内存里。缺页中断可分为主缺页中断(Major Page Fault)和次缺页中断(Minor Page Fault),要从磁盘读取数据而产生的中断是主缺页中断;数据已经被读入内存并被缓存起来,从内存缓存区中而不是直接从硬盘中读取数据而产生的中断是次缺页中断。

  上面的内存缓存区起到了预读硬盘的作用,内核先在物理内存里寻找缺页,没有的话产生次缺页中断从内存缓存里找,如果还没有发现的话就从硬盘读取。很显然,把多余的内存拿出来做成内存缓存区提高了访问速度,缓存区越大预存的页面就越多,程序运行效率越快。
查看进程产生的缺页中断次数:cat /proc/$pid/stat

zhengfeilong@zfl-HP:~$ cat /proc/2016/stat
2016 (fcitx) S 2 0 0 0 -1 69238880 0 0 0 0 0 0 0 0 0 -20 1 0 1656 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0

其中第10-13位分别对应:

min_flt=0 该任务不需要从硬盘拷数据而发生的缺页(次缺页)的次数
cmin_flt=0 累计的该任务的所有的waited-for进程曾经发生的次缺页的次数目
maj_flt=0 该任务需要从硬盘拷数据而发生的缺页(主缺页)的次数
cmaj_flt=0 累计的该任务的所有的waited-for进程曾经发生的主缺页的次数目

2.File Buffer Cache

  从上面的内存缓存区(也叫文件缓存区 File Buffer Cache)读取页比从硬盘读取页要快得多,所以 Linux 内核希望能尽可能产生次缺页中断(从文件缓存区读),并且能尽可能避免主缺页中断(从硬盘读),这样随着次缺页中断的增多,文件缓存区也逐步增大,直到系统只有少量可用物理内存的时候 Linux 才开始释放一些不用的页。例如要获取物理内存和文件缓存区的情况:

$cat /proc/meminfo:
MemTotal: 8119348 kB
MemFree: 1333676 kB
MemAvailable: 6009304 kB
Buffers: 2059668 kB
Cached: 1653252 kB

这台服务器总共有 8GB 物理内存(MemTotal),1.3GB 左右可用内存(MemFree),2GB 左右用来做磁盘缓存(Buffers),1.6GB 左右用来做文件缓存区(Cached),可见 Linux 真的用了很多物理内存做 Cache,而且这个缓存区还可以不断增长。

3.页面类型

Linux 中内存页面有三种类型:

1.Read pages,只读页(或代码页),那些通过主缺页中断从硬盘读取的页面,包括不能修改的静态文件、可执行文件、库文件等。当内核需要它们的时候把它们读到内存中,当内存不足的时候,内核就释放它们到空闲列表,当程序再次需要它们的时候需要通过缺页中断再次读到内存。
2.Dirty pages,脏页,指那些在内存中被修改过的数据页,比如文本文件等。这些文件由 pdflush 负责同步到硬盘,内存不足的时候由 kswapd 和 pdflush 把数据写回硬盘并释放内存.
3.Anonymous pages,匿名页,那些属于某个进程但是又和任何文件无关联,不能被同步到硬盘上,内存不足的时候由 kswapd 负责将它们写到交换分区并释放内存。

4.SWAP

当系统没有足够物理内存来应付所有请求的时候就会用到 swap 设备,swap 设备可以是一个文件,也可以是一个磁盘分区。( SWAP 交换分区是把物理磁盘当成内存的载体,也就是说:虽然使用 SWAP 可以让我们运行更多或更大的应用程序了,但物理磁盘的数据交换速度远比不上物理内存,因此也就可能造成运行性能的下降)。如果系统没有物理内存可用,就会频繁 swapping,如果 swap 设备和程序正要访问的数据在同一个文件系统上,那会碰到严重的 IO 问题,最终导致整个系统迟缓,甚至崩溃。swap 设备和内存之间的 swapping 状况是判断 Linux 系统性能的重要参考,我们已经有很多工具可以用来监测 swap 和 swapping 情况,比如:top、cat /proc/meminfo、vmstat 等:

$cat /proc/meminfo:
……
SwapTotal: 4096564 kB
SwapFree: 4096424 kB
……

二.Linux测试IO性能

1.测试IO读速度

  hdparm:用于显示与设定硬盘的参数
执行命令:hdparm -t —direct /dev/sda1
输出结果:

/dev/sda1:
Timing O_DIRECT disk reads: 550 MB in 3.00 seconds = 183.31 MB/sec

注释:

-t :Perform device read timings
—direct :Use O_DIRECT to bypass page cache for timings
O_DIRECT :不使用缓存直接写入.

2.测试IO写速度

  dd:用于指定大小/home/zhengfeilong/Desktop/linux_io.html的块拷贝一个文件,并在拷贝的同时进行指定的转换。
执行命令:sync;/usr/bin/time -p bash -c “(dd if=/dev/zero of=test.dd bs=1000K count=20000;sync)”
输出结果:

20000+0 records in
20000+0 records out
20480000000 bytes (20 GB) copied, 143.009 s, 143 MB/s

注释:

1.sync 命令用来刷新文件系统的缓冲区,执行sync命令实际的作用是把内存中的数据缓冲写入到磁盘中。
先执行下sync命令,是为了减少对后面测试的影响。也可以使用 echo 3 > /proc/sys/vm/drop_caches 来清除缓存。
2.time 命令用来测试命令的执行时间,shell内建还有一个time命令,我们这里使用全路径来指定使用的是非内建命令。
-p 选项设置时间的输出格式为POSIX缺省时间格式,单位是秒,在后面的测试小节可以看到time -p 的输出形式。
3.bash 命令 -c 选项的作用是将后面的字符串参数当作bash脚本来执行.
4.小括号的意思是另起一个子进程来执行括号中的脚本.
5./dev/zero该设备无穷尽地提供0,可/home/zhengfeilong/Desktop/linux_io.html以用于向设备或文件写入字符串0。

三.Linux IO监控工具inotify-tools介绍

  inotify-tools是为linux下inotify文件监控工具提供的一套c的开发接口库函数,同时还提供了一系列命令行工具,用来监控文件系统的事件。inotify-tools是用c语言编写的,除了需要内核支持inotify之外,不依赖其他。initify-tools提供了两种工具,一是inotifywait,用来监控文件或目录的变化。二是inotifywatch,用来统计文件系统访问的次数。

1.inotifywait

  语法:inotifywait -mrq —timefmt ‘%d/%m/%y/%H:%M’ —format ‘%T %w %f’ -e modify,delete,create,attrib $path
输出结果:

2014-11-27 17:34 text.txt CREATE
2014-11-27 17:34 text.txt CLOSE_WRITE,CLOSE
2014-11-27 17:34 ttt.t MOVED_TO
2014-11-27 17:35 bb DELETE

参数说明:

-m是要持续监视变化。
-r使用递归形式监视目录。
-q减少冗余信息,只打印出需要的信息。
-e指定要监视的事件列表。
—timefmt是指定时间的输出格式。
—format指定文件变化的详细信息。

Events: 事件

access file or directory contents were read 文件或目录被(访问)读取r
modify file or directory contents were written 文件或目录被写入w
attrib file or directory attributes changed 文件或目录属性变更【理由:chmod更改属性】
close_write file or directory closed, after being opened in writeable mode 文件或目录被写关闭【理由:文件内容被更改】
close_nowrite file or directory closed, after being opened in read-only mode 文件或目录以只读方式打开后关闭
close file or directory closed, regardless of read/write mode 文件或目录被用编辑器(不管是读或写)关闭
open file or directory opened 文件或目录被用编辑器打开
moved_to file or directory moved to watched directory 文件或目录被移动进来【理由:mv目录内重命名】
moved_from file or directory moved from watched directory 文件或目录被移动出去
move file or directory moved to or from watched directory 文件或目录不管是移出或移进
create file or directory created within watched directory 文件或目录被创建【理由:mkdir创建目录】
delete file or directory deleted within watched directory 文件或目录被删除【理由:rm删除】
delete_self file or directory was deleted 文件或目录自删除
unmount file system containing file or directory unmounted 文件系统取消挂载

2.inotifywatch

  语法:inotifywatch [-hvr] [-e] [-t] [-a] [-d] file1 [file2] [file3] […]
参数说明:

-h:输出帮助信息
-v:输出详细信息
-r:监视一个目录下的所有子目录
-t:设置超时时间
-e:只监听指定的事件
-a:以指定事件升序排列。
-d:以指定事件降序排列

示例:
创建一个目录,并监听该目录:

zhengfeilong@zfl-HP:~$ mkdir tmpdir
zhengfeilong@zfl-HP:~$ inotifywatch -v -e access -e modify -t 60 -r tmpdir/
Establishing watches…
Setting up watch(es) on tmpdir/
OK, tmpdir/ is now being watched.
Total of 1 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 60 seconds.

在另一终端,执行一下操作:

zhengfeilong@zfl-HP:~$ date > tmpdir/foo.txt
zhengfeilong@zfl-HP:~$ cat tmpdir/foo.txt

输出结果:

total   access   modify  filename
5     3     2     tmpdir/

2010-12-29 11:35:00 siemens800 阅读数 45

 

RedHat Linux LVM   LVM - 很好很强大

http://www.iteye.com/topic/283065

LVM (Logic Volume Management,逻辑卷管理),是传统商业Unix就带有的一项高级磁盘管理工具,异常强大。后来LVM移植到了Linux操作系统上,尽管不像原 来Unix版本那么强大,但瘦死的骆驼比马大,Linux的LVM仍然非常强大,可以在生产运行系统上面直接在线扩展硬盘分区,可以把分区umount以 后收缩分区大小,还可以在系统运行过程中把一个分区从一块硬盘搬到另一块硬盘上面去等等,简直就像变魔术,而且这一切都可以在一个繁忙运行的系统上面直接 操作,不会对你的系统运行产生任何影响,很安全。
还是拿JavaEye的网站服务器随便举个小例子吧。话说今天晚上我登录JavaEye网站服务器随便这么一查看磁盘使用状况:

C代码
  1. df -h  
df -h

竟然发现/home分区的磁盘消耗的很快

C代码
  1. Filesystem                Size  Used  Avail Use%   Mounted on  
  2. /dev/mapper/system-home    40G   32G    8G  80%    /home  
Filesystem                Size  Used  Avail Use%   Mounted on
/dev/mapper/system-home    40G   32G    8G  80%    /home

有点出乎意料,已经使用了80%,如果用光了,可就有点麻烦了,所以为了安全,把/home分区扩大5GB,多给它点硬盘空间,敲入两条shell命令

C代码
  1. lvextend -L +5G /dev/system/home  
  2. resize_reiserfs -s +5G /dev/system/home   
lvextend -L +5G /dev/system/home
resize_reiserfs -s +5G /dev/system/home 

先把逻辑卷扩大5GB,再把上面的reiserfs文件系统扩大5GB,前后耗时不超过3秒钟。再df -h查看一下:

C代码
  1. Filesystem                Size  Used  Avail Use%   Mounted on  
  2. /dev/mapper/system-home    45G   32G    13G  71%    /home  
Filesystem                Size  Used  Avail Use%   Mounted on
/dev/mapper/system-home    45G   32G    13G  71%    /home

哈哈,/home立刻多了5GB,搞定收工,这是不是很像变戏法,我没停任何服务,没重起服务器,大家没有任何感觉,就一切搞定,说实话我也一直 觉得LVM很cool,所以我一直是LVM+Reiserfs的忠实拥趸。有兴趣学习LVM的同学可以下载后面的附件,这可是我珍藏多年的LVM秘籍!
另外强烈推荐Daniel Robbins在IBM DW网站上面关于LVM的系列文章:
通用线程: 学习 Linux LVM,第 1 部分
通用线程:学习 Linux LVM,第 2部分
另外,在大规模的生产系统上面,文件系统的管理是一个错综复杂的工作,如果你对这个方面的知识很感兴趣,你可以继续了解一下 EVMS(Enterprise Volume Management System,企业级文件卷管理系统)。EVMS 为 Linux 下的所有存储技术提供了统一的、可扩展的、基于插件的 API。这意味着什么?它意味着由于 EVMS,您可以使用单个工具来对磁盘分区、创建 LVM 对象以及甚至创建 Linux 软件 RAID 卷。并且可以使用这一工具以强有力的方式合并这些技术。还是推荐看Daniel Robbins的文章:
通用线程: 高级文件系统实现者指南,第 12 部分 EVMS 简介
通用线程: 高级文件系统实现者指南,第 13 部分EVMS 详情
BTW:Daniel Robbins在IBM DW所有的文章都值得一读,特别是《通用线程: 高级文件系统实现者指南》这个系列。

RedHat Linux Disk mount / 翟翔(13110508)

磁盘状态为加载过,分两种情况:

A、虚拟机删除,数据盘未删除;

B、虚拟机迁移,原物理机上数据盘未删除。

umount 的时候报错:device is busy

http://liuyu.blog.51cto.com/183345/64044

今天刚上服务器习惯的用了输入:
 df -HT
查看到有移动硬盘挂载在/mnt/usbdisk目录下...
想必是上次没有umount  
执行umount 的时候却提示:device is busy  
强行: umount /dev/sdb2 -f
提示:umount2: 设备或资源忙
umount: /mnt/usbdisk: device is busy
有人在使用...查看一样使用情况: fuser -m /mnt/usbdisk    
有 6406 进程在使用..
ps aux | grep 6406
再kill
接着umount 提示还是失败...
接着 fuser -k /mnt/usbdisk
提示:
/mnt/usbdisk/:        6406c
No automatic removal. Please use  umount /mnt/usbdisk
按提示操作: umount /mnt/usbdisk  OK    搞定!

 

 

linux分区知识与大磁盘的分区

http://www.iteye.com/topic/521107

引用
目前我们可以接触到的大部分pc依 然采用上世纪遗传下来的 BIOS + MBR 组合。 BIOS,基本输入输出系统 (Basic Input-Output System),是软件与硬件之间的一个接口,可以把它看作一个翻译在中文与英语之间,虽然两者完全不同,不过可以让大家了解 BIOS 所处的位置,BIOS 通常被写入一块 ROM 芯片连接在主板上,当然也有直接写入北桥的,不过相当少见。 BIOS 几乎是完全用汇编语言编写,很大程度上决定了主板的性能及稳定性。
MBR ,主引导记录 (Master Boot Record),也就是我们常见的分区方法,不过管理员外的最终用户很少知道它的存在,MBR 分区的标准决定了 MBR 只支持在2TB以下 (超过 2TB 的只能管理 2TB) 的硬盘中创建4个分区表项,要获得更多分区,需要次级结构–扩展分区。扩展分区可以再次被分成一个或多个逻辑磁盘,也就是普通情况下的C盘以外的盘,或说 第一个分区以外的部分,有些情况下 Windows 里的C盘可能会是一个逻辑分区。
EFI ,可扩展固件接口 (Extensible Firmware Interface),由英特尔 (Intel) 公司提出的一种替代 BIOS 的升级方案。 EFI 的位置很特殊,它不像是 BIOS 那样自己即是固件又是接口,EFI 只是一个接口,位于操作系统与平台固件之间,感觉像是公司、CEO、CEO秘书之间的关系一样,由CEO (操作系统) 下任务,CEO秘书 (EFI) 负责把任务分配下发到公司各部门经理 (平台固件),经理们又把任务下发到具体的小组 (各类硬件) 去完成。
GPT ,全局唯一标识磁盘分区表 (GUID Partition Table),GUID,全局唯一标识符 (Globally Unique Identifier) 。GUID 分区表 (GPT) 是作为 Extensible Firmware Interface (EFI) 计划的一部分引入的。当然,你也可以在 BIOS 的PC中使用 GPT 分区,虽然 GPT 来自以 EFI 计划,但并不依赖于 EFI。GPT 相对于以往 PC 普遍使用的主引导记录 (MBR) 分区方案更加灵活。比如可以超过 MBR 分区表项4个的限制,在 GPT 规范里对分区的数量几乎是没有限制的,大家在网上可以查到的128个实际上是 Windows 系统 (支持 GPT 的 Windows) 做出的限制。 GPT 对可管理磁盘大小也超过了 MBR 的2TB (1TB = 1024GB) 而达到了 18EB (1EB = 1024TB) 。在 MBR 分区方案中操作系统的引导是通过放在磁盘最开始 (第一扇区) 里的 MBR (这里的 MBR 是指主引导记录,而不是主引导记录分区方案,两者是同名的。我的猜测是为了与 GPT 分区方案区分,使用了主引导记录引导方式的名字 MBR 来命名此种分区方案,我查不到确切的资料正明我的猜测是否正确,只能大家努力区分一下了。) 。把重要的信息 (如分区信息、目录等) 放在某个扇区里是 MBR 分区方案的方法,而 GPT 把这个信息放到了分区里,Intel的解释是这样可以更加明确更加安全。 GPT 分区为了保护自己不受 MBR 方案下磁盘管理软件的危害,在磁盘的最开始位置 (第一个扇区) 建立了一个保护分区 (Protective MBR),这种分区的类型标识为 0xEE。苹果系统 (Mac OS X) 下这个保护分区大小为 200MB,这个分区在 Window NT 磁盘管理器里名字叫做 GPT 保护分区。这个分区可以让不能识别 GPT 的磁盘管理软件把 GPT 磁盘看成一个未知格式的分区,而不是错误地当成一个未分区的磁盘。

 

文件系统限制:


以下信息出自:维基百科
ext3
块尺寸 最大文件尺寸 最大文件系统尺寸
1KiB 16GiB 2TiB
2KiB 256GiB 8TiB
4KiB 2TiB 16TiB
8KiB 16TiB 32TiB
ext4
Extents
    ext4引进了Extent档案储存方式,以取代ext2/3使用的block mapping方式。Extent指的是一连串的连续实体block,这种方式可以增加大型档案的效率并减少分裂档案。ext4支援的单一Extent, 在单一block为4KB的系统中最高可达128MB[1]。单一inode中可储存4笔Extent;超过四笔的Extent会以Htree方式被索 引。
最大文件尺寸 16 TiB (for 4k block filesystem)
最大卷容量 1 EiB
xfs
最大可支持的文件大小为263 = 9 x 1018 = 9 exabytes,最大文件系统尺寸为18 exabytes。
ReiserFS
最大文件尺寸 8 TiB
最大卷容量 16 TiB

大于2T的磁盘分区方法

...balabala...

GPT硬盘不能用于lvm ?

 

 

Linux LVM-逻辑卷管理 / Apache Traffic Server / ATS Cache Server

http://wiki.cns*****.com/pages/viewpage.action?pageId=17403026

Linux LVM-逻辑卷管理

场景:

       CDN节点上安装完atsApache Trafficserver)后,配置ats,需要指定一个大的磁盘用来存放cache。根据服务器的分区情况,分两种操作

1、查看磁盘分区:

http://dl2.iteye.com/upload/attachment/0101/0028/30f34a85-0583-397c-a399-07cae20a40ef.png

存在一个独立的大磁盘分区挂载到/cache 目录,此时只需要将atscache目录配置为: /cache 350G

2、查看磁盘分区

http://dl2.iteye.com/upload/attachment/0101/0032/5917480e-7a89-35ff-a33b-e2d2925cc46d.png

不存在足够大的分区(400G左右)供ats存放缓存

我们只能选择一个裸盘 ats使用,默认我们选择 /dev/sda2

问题:

但是使用/dev/sda2的服务器发生了问题,服务器运行一段时间后,系统down掉,解决方法:只能重装系统。

分析问题:

分析后,定位原因:

fdisk -l  # fdisk -l 可以列出所有的分区,包括没有挂上的分区和usb设备,

http://dl2.iteye.com/upload/attachment/0101/0036/df8e7a47-3b58-399c-afd7-2498a1e13fb4.png

我们选择使用的 /dev/sda2  Id8e,即分区的类型是 Linux LVM

=============

Linux LVM的说明:

LVM的全称为Logical Volume Manager,它是Linux环境下对磁盘分区进行管理的一种机制,
LVM
是建立在硬盘和分区之上的一个逻辑层,来提高磁盘分区管理的灵活性。
通过LVM系统管理员可以轻松管理磁盘分区,如:将若干个磁盘分区连接为一个整块的卷组(volume group),形成一个存储池。
管理员可以在卷组上随意创建逻辑卷组(logical volumes),并进一步在逻辑卷组上创建文件系统

在以往的Linux系统中(比Redhat AS4更早的版本),默认是不支持LVM逻辑卷管理的
当磁盘连接到服务器后,使用fdisk将其划分为主分区和扩展分区
随后直接把分区进行格式化,生成诸如/dev/sda1/dev/sda2之类的分区
这些分区可以直接用mount命令挂载到目录来使用
当应用了LVM后,磁盘分区类型为Linux LVM/dev/sda1/dev/sda2这样的分区会被LVM认为是一整个VG,即卷组
这样的卷组是不能直接挂载的,需要由LVM转换成类似/dev/mapper/这样的VG卷组,每个VG又包含LV(逻辑卷),想要使用他们只需要将逻辑卷挂载到目录

==================

解决方法:

使用卷组查看命令vgdisplay查看卷组情况

http://dl2.iteye.com/upload/attachment/0101/0040/9b6b943f-79fb-3561-be19-a5a3a6d0ec2f.png

 

卷组名为:systemvg

可用大小:475G

步骤:

1、创建逻辑卷LVLogical Volumes),命名为:cachelv,所属的卷组VGVolume Groups)为systemvg,-L指定逻辑分区大小为400G

lvcreate -n cachelv -L 400G systemvg

2、创建文件系统

mkfs.ext4 /dev/systemvg/cachelv

3、挂载

mount /dev/systemvg/cachelv /cache

4、添加到 fstab #fstab可以自动挂载各种文件系统格式的硬盘、分区、可移动设备和远程设备等

vi /etc/fstab
/dev/systemvg/cachelv  /cache  ext4  defaults  0 0

以上操作完成后,df -h 查看:

http://dl2.iteye.com/upload/attachment/0101/0044/e0ce5705-2c1a-3232-8445-2b184020dc40.png

 

atscache目录指定为 /cache ok

 

“苏*宁公有云”项目

http://eitp.cns*****.com/itp-web-in/resourcepool/resourceInfoRead.htm?employeeid=13073414

需求描述:

1、整合苏宁上游的服务提供者和下游最终用户,打造新的价值链和生态系统。

2、与竞品京东云、阿里云等竞争,积极扩大苏宁的用户群,提升苏宁的技术实力。

3、通过公有云项目,积极参与到开源技术领域,扩大苏宁在技术行业的影响力。

解决方案描述:

1. 搭建基于Cloudstack的公有云平台,使用KVM作为虚拟化层支撑。

2. 搭建苏宁公有云平台作为自助式管理门户,提供服务。

LVM数据丢失,替换数据盘

http://wiki.cns*****.com/pages/viewpage.action?pageId=19368510

Cloudstack资料收集

Cloudstack运维及优化

Openstack部署运维

Openstack技术调研

Openstack业界动态

苏*宁私有云支撑

File Lists

苏宁公有云支撑 

CS问题对应列表

RDS 问题对应列表

对象存储问题列表

系统相关 

LVM数据丢失,替换数据盘

http://wiki.cns*****.com/pages/viewpage.action?pageId=19368510

一、缘由

       在linux虚机通过LVM将数据盘拓展到了opt目录,在数据盘损坏以后,使用新的数据盘替换损坏的数据盘。

二、操作

     1.卸载源数据盘、添加新数据盘

     2.创建PV:pvcreate /dev/vdc
                       lvremove /dev/systemvg/optlv
                       vgreduce --removemissing systemvg
                       vgextend systemvg /dev/vdc
                       l
vcreate /dev/systemvg/optlv
                       lvcreate -n optlv -L 79G systemvg
                       mkfs.ext4 /dev/systemvg/optlv
                       mount /dev/systemvg/optlv /opt/

     3.最后重启服务器验证 

小结一下linux 2.6内核的四种IO调度算法

http://jackyrong.iteye.com/blog/898938

  在LINUX 2.6中,有四种关于IO的调度算法,下面综合小结一下: 

linux IO调度算法

http://www.cnblogs.com/cutepig/p/3403711.html


1) NOOP (电梯式调度程序)
NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列,所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”,原因是NOOP在FIFO的基础上还做了相邻IO请求的合并,并不是完完全全按照先进先出的规则满足IO请求。NOOP假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有些SAN环境下,这个选择可能是最好选择。Noop 对于 IO 不那么操心,对所有的 IO请求都用 FIFO 队列形式处理,默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然,对于复杂一点的应用类型,使用这个调度器,用户自己就会非常操心。 



2) Deadline scheduler (截止时间调度程序)
  DEADLINE在CFQ的基础上,解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外,DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms,写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高,,而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下: 
FIFO(Read) > FIFO(Write) > CFQ 
    deadline 算法保证对于既定的 IO 请求以最小的延迟时间,从这一点理解,对于 DSS 应用应该会是很适合的。 
  

3) Anticipatory scheduler (预料I/O调度程序)
  CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms 
的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足 
   Anticipatory scheduler(as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点,简单的说,有个 IO 发生的时候,如果又有进程请求 IO 操作,则将产生一个默认的 6 毫秒猜测时间,猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时,对数据库应用很糟糕,而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的,因为那个”猜测”实际上的目的是为了减少磁头移动时间。 

4)CFQ (完全公平排队I/O调度程序)
  CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序,而不是按照先来后到的顺序来进行响应。 
   在传统的SAS盘上,磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序,以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下,SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是,先来的IO请求并不一定能被满足,可能会出现饿死的情况。 
   Completely Fair Queuing (cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列,各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中,SuSE Linux 好像是最先默认用 cfq 的. 

查看和修改IO调度器的算法非常简单。假设我们要对sda进行操作,如下所示: 
cat /sys/block/sda/queue/scheduler 
echo “cfq” > /sys/block/sda/queue/scheduler 

总结: 
  1 CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足。 

IO调度器算法的选择,既取决于硬件特征,也取决于应用场景。 
在传统的SAS盘上,CFQ、DEADLINE、ANTICIPATORY都是不错的选择;对于专属的数据库服务器,DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上,最简单的NOOP反而可能是最好的算法,因为其他三个算法的优化是基于缩短寻道时间的,而固态硬盘没有所谓的寻道时间且IO响应时间非常短。 

  2 对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点,而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3,整体 IO 改进还是不小的。 

 

IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯. (elevator)而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做 cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation).具体使用哪种算法我们可以在启动的时候通过内核参数elevator来指定.


一)I/O调度的4种算法

1)CFQ(完全公平排队I/O调度程序)

特点:
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.
CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.
CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.
CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级.


工作原理:
CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,
以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求.


2)NOOP(电梯式调度程序)

特点:
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.
NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.
NOOP倾向饿死读而利于写.
NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.

电梯算法饿死读请求的解释:
因为写请求比读请求更容易.
写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.
读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.

3)Deadline(截止时间调度程序)

特点:
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.
Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.
Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择.


4)AS(预料I/O调度程序)

特点:
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.
可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.
它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.
AS适合于写入较多的环境,比如文件服务器
AS对数据库环境表现很差.

查看当前系统支持的IO调度算法
dmesg | grep -i scheduler

[root@localhost ~]# dmesg | grep -i scheduler
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)

查看当前系统的I/O调度方法:

cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

临地更改I/O调度方法:
例如:想更改到noop电梯调度算法:
echo noop > /sys/block/sda/queue/scheduler

想永久的更改I/O调度方法:
修改内核引导参数,加入elevator=调度程序名
vi /boot/grub/menu.lst
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet


重启之后,查看调度方法:
cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
已经是deadline了

 

四)I/O调度程序的测试

本次测试分为只读,只写,读写同时进行.
分别对单个文件600MB,每次读写2M,共读写300次.

1)测试磁盘读:
[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.81189 seconds, 92.4 MB/s

real 0m6.833s
user 0m0.001s
sys 0m4.556s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.61902 seconds, 95.1 MB/s

real 0m6.645s
user 0m0.002s
sys 0m4.540s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 8.00389 seconds, 78.6 MB/s

real 0m8.021s
user 0m0.002s
sys 0m4.586s
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 29.8 seconds, 21.1 MB/s

real 0m29.826s
user 0m0.002s
sys 0m28.606s
结果:
第一 noop:用了6.61902秒,速度为95.1MB/s
第二 deadline:用了6.81189秒,速度为92.4MB/s
第三 anticipatory:用了8.00389秒,速度为78.6MB/s
第四 cfq:用了29.8秒,速度为21.1MB/s


2)测试写磁盘:
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.93058 seconds, 90.8 MB/s

real 0m7.002s
user 0m0.001s
sys 0m3.525s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.79441 seconds, 92.6 MB/s

real 0m6.964s
user 0m0.003s
sys 0m3.489s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 9.49418 seconds, 66.3 MB/s

real 0m9.855s
user 0m0.002s
sys 0m4.075s
[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.84128 seconds, 92.0 MB/s

real 0m6.937s
user 0m0.002s
sys 0m3.447s

测试结果:
第一 anticipatory,用了6.79441秒,速度为92.6MB/s
第二 deadline,用了6.84128秒,速度为92.0MB/s
第三 cfq,用了6.93058秒,速度为90.8MB/s
第四 noop,用了9.49418秒,速度为66.3MB/s


3)测试同时读/写

[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 15.1331 seconds, 41.6 MB/s
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 36.9544 seconds, 17.0 MB/s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 23.3617 seconds, 26.9 MB/s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 17.508 seconds, 35.9 MB/s

测试结果:
第一 deadline,用了15.1331秒,速度为41.6MB/s
第二 noop,用了17.508秒,速度为35.9MB/s
第三 anticipatory,用了23.3617秒,速度为26.9MS/s
第四 cfq,用了36.9544秒,速度为17.0MB/s

五)ionice

ionice可以更改任务的类型和优先级,不过只有cfq调度程序可以用ionice.
有三个例子说明ionice的功能:
采用cfq的实时调度,优先级为7
ionice -c1 -n7 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
采用缺省的磁盘I/O调度,优先级为3
ionice -c2 -n3 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
采用空闲的磁盘调度,优先级为0
ionice -c3 -n0 -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&

ionice的三种调度方法,实时调度最高,其次是缺省的I/O调度,最后是空闲的磁盘调度.
ionice的磁盘调度优先级有8种,最高是0,最低是7.
注意,磁盘调度的优先级与进程nice的优先级没有关系.
一个是针对进程I/O的优先级,一个是针对进程CPU的优先级.

 

Anticipatory I/O scheduler 适用于大多数环境,但不太合适数据库应用

Deadline I/O scheduler 通常与Anticipatory相当,但更简洁小巧,更适合于数据库应用

CFQ I/O scheduler 为所有进程分配等量的带宽,适合于桌面多任务及多媒体应用,默认IO调度器

Default I/O scheduler

 

问题一:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sdi 82.40 8.90 67.00 5.30 8641.20 56.80 240.61 0.08 1.09 0.93 6.76

上面sdi是一块SSD盘,SSD又不是机械盘,怎么会有rrqm这些合并值呢?

我的理解是内核把这些指标统一对待了? 意思是这些指标对SSD不适用


问题二:
SSD的%util参数很低,但是明显感觉SSD性能到瓶颈了,难道说%util参数也是打酱油的?

 

end

2011-03-02 16:04:00 xuyubotest 阅读数 799

Extreme Linux Performance Monitoring Part II


I. Introducing IO Monitoring

Disk IO subsystems are the slowest part of any Linux system. This is due mainly to their distance from the CPU and the fact that disks require the physics to work (rotation and seek). If the time taken to access disk as opposed to memory was converted into minutes and seconds, it is the difference between 7 days and 7 minutes. As a result, it is essential that the Linux kernel minimizes the amount

of IO it generates on a disk. The following subsections describe the different ways the kernel

processes data IO from disk to memory and back.


Reading and Writing Data Memory Pages
The Linux kernel breaks disk IO into pages. The default page size on most Linux systems is 4K.

It reads and writes disk blocks in and out of memory in 4K page sizes. You can check the page size of your system by using the time command in verbose mode and searching for the page size:


# /usr/bin/time -v date
<snip>
Page size (bytes): 4096
<snip>


Major and Minor Page Faults
Linux, like most UNIX systems, uses a virtual memory layer that maps into physical address space.

This mapping is "on demand" in the sense that when a process starts, the kernel only maps that

which is required. When an application starts,the kernel searches the CPU caches and then physical memory. If the data does not exist in either, the kernel issues a major page fault (MPF). A MPF is a request to the disk subsystem to retrieve pages off disk and buffer them in RAM.
Once memory pages are mapped into the buffer cache, the kernel will attempt to use these pages resulting in a minor page fault (MnPF).

A MnPF saves the kernel time by reusing a page in memory as opposed to placing it back on the disk.
In the following example, the time command is used to demonstrate how many MPF and MnPF

occurred when an application started. The first time the application starts, there are many MPFs:


# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
<snip>

The second time evolution starts, the kernel does not issue any MPFs because the application is in memory already:


# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
<snip>


The File Buffer Cache
The file buffer cache is used by the kernel to minimize MPFs and maximize MnPFs. As a system

generates IO over time,
this buffer cache will continue to grow as the system will leave these pages in memory until memory

gets low and the kernel needs to "free" some of these pages for other uses. The end result is that

many system administrators see low amounts of free memory and become concerned when in reality, the system is just making good use of its caches.


The following output is taken from the /proc/meminfo file:
# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
<snip>


The system has a total of 2 GB (MemTotal) of RAM available on it. There is currently 52 MB of RAM

"free" (MemFree),
24 MB RAM that is allocated to disk write operations (Buffers), and 1.7 GB of pages read from disk

in RAM (Cached).
The kernel is using these via the MnPF mechanism as opposed to pulling all of these pages in from

disk.It is impossible to tell from these statistics whether or not the system is under distress as we only have part of the picture.


Types of Memory Pages
There are 3 types of memory pages in the Linux kernel. These pages are described below:


 Read Pages These
are pages of data read in via disk (MPF) that are read only and backed on disk. These pages exist in

the Buffer Cache and include static files, binaries, and libraries that do not change. The Kernel will continue to page these into memory as it needs them. If memory becomes short,

the kernel will "steal" these
pages and put them back on the free list causing an application to have to MPF to bring them back in.


 Dirty Pages

These are pages of data that have been modified by the kernel while in memory. These pages
need to be synced back to disk at some point using the pdflush daemon. In the event of a memory shortage,
kswapd (along with pdflush) will write these pages to disk in order to make more room in memory.


 Anonymous Pages

These are pages of data that do belong to a process, but do not have any file or backing
store associated with them. They can't be synchronized back to disk. In the event of a memory shortage, kswapd
writes these to the swap device as temporary storage until more RAM is free ("swapping" pages).



Writing Data Pages Back to Disk
Applications themselves may choose to write dirty pages back to disk immediately using the fsync() or sync() system calls. These system calls issue a direct request to the IO scheduler. If an application

does not invoke these system calls, the pdflush kernel daemon runs at periodic intervals and writes pages back to disk.


# ps -ef | grep pdflush
root 186 6 0 18:04 ? 00:00:00 [pdflush]

 t405583 10895 15474   0 15:13:19 pts/9       0:00 grep pdflush


II. Monitoring IO
Certain conditions occur on a system that create IO bottlenecks. These conditions may be identified

by using a standard
set of system monitoring tools. These tools include top, vmstat, iostat, and sar. There are some similarities
between the output of these commands, but for the most part, each offers a unique set of output

that provides a different
aspect on performance. The following subsections describe conditions that cause IO bottlenecks.
Condition 1: CPU Wait on IO Too
Much IO at Once
In an ideal environment, a CPU splits a percentage of its time between user (65%), kernel (30%) and idle (5%). If IO starts
to cause a bottleneck on the system, a new condition called "Wait on IO" (WIO) appears in CPU performance statistics. A
WIO condition occurs when a CPU is completely idle because all runnable processes are waiting on IO. This means that
all applications are in a sleep state because they are waiting for requests to complete in the IO subsystem.


The vmstat command provides WIO statistics in the last 4 fields of output under the "cpu" header.


# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57
2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52
2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52


These last 4 columns provide percentages of CPU utilization for user (us), kernel (sys), idle (id), and

WIO (wa). In theprevious output, the CPU averages 50% idle waiting on IO requests to complete.

This means that there is 50% of the
processor that is usable for executing applications, but no applications can execute because the

kernel is waiting on IO
requests to complete. You can observe this in the blocked threads column (b).
It is also worth noting that the major cause of the IO bottleneck is disk reads due to the large

amount of disk blocks read
into memory (bi). There is no data being written out to disk as the blocks out (bo) column has a zero value. From this
output alone, it appears that the system is processing a large IO request.
The sar command without any options also provides CPU percentages that include WIO (%iowait) percentages:


# sar 1 100


07:25:55 PM CPU %user %nice %system %iowait %idle
07:25:56 PM all 74.26 0.00 25.74 0.00 0.00
07:25:57 PM all 52.00 0.00 31.00 16.00 1.00
07:25:58 PM all 12.87 0.00 13.86 73.27 0.00


The sar command with the -B option provides statistics on kilobytes read (pgpgin/s) and written out (pgpgout/s) of
memory that may be correlated with the bi and bo columns of vmstat.

The sar -B command also shows MnPF (fault/s) and MPF statistics (majflt/s).


# sar -B 1 100


07:28:23 PM pgpgin/s pgpgout/s fault/s majflt/s
07:28:24 PM 6653.47 463.37 1604.95 74.26
07:28:25 PM 7448.00 96.00 2061.00 79.00
07:28:26 PM 4190.10 118.81 723.76 30.69
07:28:27 PM 2966.34 146.53 525.74 9.90
07:28:28 PM 3728.00 0.00 146.00 6.00
07:28:29 PM 5244.00 580.00 927.00 39.00
There is no exact tool that can identify which application is causing the IO read requests.

The top tool can provide enough insight to make an educated guess. Start the top command with a delay of 1 second:


# top -d 1
Once top is running, sort the output by faults (MPF and MnPF) by typing "F" to bring up the sort menu and "u" to sort by faults.


# top -d 1


top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40
Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si
Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers
Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND
3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx
3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx
3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx
3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx


<snip>
The previous output demonstrates that a series of VMWare process are causing the majority of page faults (nFLT) which
would contribute to the surge of read requests seen in the previous commands.

This surge has caused the WIO condition on the system, rendering the CPU idle and causing the

system to appear much slower.
Condition 2: Pipes Too Small Read and Write Efficiency
Every IO request to a disk takes a certain amount of time. This is due primarily to the fact that a disk must spin and a head
must seek. The spinning of a disk is often referred to as "rotational delay" (RD) and the moving of the head as a "disk
seek" (DS). The time it takes for each IO request is calculated by adding DS and RD.
A disk's RD is fixed based on the RPM of the drive. An RD is considered half a revolution around a

disk.

 

To calculate RD for a 10K RPM drive, perform the following:


1. Divide 10000 RPM by 60 seconds (10000/60 = 166 RPS)
2. Convert 1 of 166 to decimal (1/166 = 0.0006 seconds per Rotation)
3. Multiply the seconds per rotation by 1000 milliseconds (6 MS per rotation)
4. Divide the total in half (6/2 = 3 MS) or RD
5. Add an average of 3 MS for seek time (3 MS + 3 MS = 6 MS)
6. Add 2 MS for latency (internal transfer) (6 MS + 2 MS = 8MS)
7. Divide 1000 MS by 8MS per IO (1000/8 = 125 IOPS)


Each time an application issues an IO, it takes an average of 8MS to service that IO on a 10K RPM

disk. Since this is a fixed time, it is imperative that the disk be as efficient as possible with the time it will spend reading and writing to the disk.
The amount of IO requests are often measured in IOs Per Second (IOPS). The 10K RPM disk has the ability to push 120
to 150 (burst) IOPS. To measure the effectiveness of IOPS, divide the amount of IOPS by the

amount of data read or
written for each IO.
Random vs Sequential IO
The relevance of KB per IO depends on the workload of the system. There are two different types of workload categories
on a system. They are sequential and random.
Sequential IO
The iostat command provides information about IOPS and the amount of data processed during each

IO. Use the -x switch with iostat. Sequential workloads require large amounts of data to be read sequentially and at once. These
include applications like enterprise databases executing large queries and streaming media services capturing data. With
sequential workloads, the KB per IO ratio should be high. Sequential workload performance relies on

the ability to move large amounts of data as fast as possible. If each IO costs time, it is imperative to

get as much data out of that IO as possible.


# iostat -x 1


<snip>
avg-cpu: %user %nice %sys %idle
0.00 0.00 57.14 42.86
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/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00
/dev/sda1 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
/dev/sda2 0.00 12857.14 0.00 5.71 0.00 105782.86 0.00 52891.43 18512.00 559.14 780.00 490.00 280.00
/dev/sda3 0.00 34.29 0.00 100.00 0.00 297.14 0.00 148.57 2.97 540.29 3594.57 24.00 240.00
avg-cpu: %user %nice %sys %idle
0.00 0.00 23.53 76.47
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/sda 0.00 17320.59 0.00 102.94 0.00 142305.88 0.00 71152.94 1382.40 6975.29 952.29 28.57 294.12
/dev/sda1 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
/dev/sda2 0.00 16844.12 0.00 102.94 0.00 138352.94 0.00 69176.47 1344.00 6809.71 952.29 28.57 294.12
/dev/sda3 0.00 476.47 0.00 0.00 0.00 3952.94 0.00 1976.47 0.00 165.59 0.00 0.00 276.47

The way to calculate the efficiency of IOPS is to divide the reads per second (r/s) and writes per

second (w/s) by the kilobytes read (rkB/s) and written (wkB/s) per second. In the above output, the amount of data written per IO for /dev/sda increases during each iteration:
53040/105 = 505KB per IO
71152/102 = 697KB per IO
Random IO
Random access workloads do not depend as much on size of data. They depend primarily on the

amount of IOPS a disk
can push. Web and mail servers are examples of random access workloads. The IO requests are

rather small. Random
access workload relies on how many requests can be processed at once. Therefore, the amount

of IOPS the disk can
push becomes crucial.
# iostat -x 1
avg-cpu: %user %nice %sys %idle
2.04 0.00 97.96 0.00
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/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00
/dev/sda1 0.00 5.10 0.00 2.04 0.00 57.14 0.00 28.57 28.00 1.12 55.00 55.00 11.22
/dev/sda2 0.00 628.57 3.06 100.27 24.49 5224.49 12.24 2612.24 321.50 72.55 121.25 30.63 50.00
/dev/sda3 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
avg-cpu: %user %nice %sys %idle
2.15 0.00 97.85 0.00
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/sda 0.00 41.94 6.45 130.98 51.61 352.69 25.81 3176.34 19.79 2.90 286.32 7.37 15.05
/dev/sda1 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
/dev/sda2 0.00 41.94 4.30 130.98 34.41 352.69 17.20 3176.34 21.18 2.90 320.00 8.24 15.05
/dev/sda3 0.00 0.00 2.15 0.00 17.20 0.00 8.60 0.00 8.00 0.00 0.00 0.00 0.00
The previous output shows that the amount of IOPS for writes stays almost the same as the

sequential output. The
difference is the actual write size per IO:
2640/102 = 23KB per IO
3176/130 = 24KB per IO
Condition 3: Slow Disks
Many disk configurations may not be a physical disk on the system. Some may be part of a volume group, NAS, shared
drive, or SAN. It is possible to measure the latency between the request time and the actual service

time of a device.

The following output was taken from a system with Linux volume groups under extreme sequential IO write access.
# iostat -x 1
<snip>
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 30.94 8.19 60.37
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 2610.03 0.00 6.02 0.00 20984.62 0.00 10492.31 3485.78 8.59 315.28 56.50 34.01
hdb 0.00 2610.03 0.00 6.02 0.00 20984.62 0.00 10492.31 3485.78 8.40 284.56 56.44 33.98
md0 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
md1 0.00 0.00 0.00 2622.74 0.00 20981.94 0.00 10490.97 8.00 0.00 0.00 0.00
0.00
avg-cpu: %user %nice %sys %iowait %idle
0.83 0.00 59.27 4.01 35.89
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 13595.64 0.00 10.07 0.00 109197.32 0.00 54598.66 10846.93 95.15 1872.43 100.07 100.74
hdb 0.00 13595.64 0.00 10.40 0.00 109197.32 0.00 54598.66 10497.03 94.64 1854.52 96.84 100.74
md0 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
md1 0.00 0.00 0.00 13649.66 0.00 109197.32 0.00 54598.66 8.00 0.00 0.00 0.00 0.00
avg-cpu: %user %nice %sys %iowait %idle
0.34 0.00 20.94 62.31 16.42
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 3420.07 0.00 11.37 0.00 27478.26 0.00 13739.13 2416.47 158.53 2997.18 88.24 100.33
hdb 0.00 3420.07 0.00 11.37 0.00 27478.26 0.00 13739.13 2416.47 157.97 2964.79 88.24 100.33
md0 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
md1 0.00 0.00 0.00 3434.78 0.00 27478.26 0.00 13739.13 8.00 0.00 0.00 0.00
0.00
The previous iostat output monitors a RAID 1 device (/dev/md/1). Notice the difference between the service time
(svctm) and the average wait time (await). Both of these values are in milliseconds. The actual time it takes to service
the request is minimal compared to the time the system spends waiting for the response.
Since a mirror has to sync to another disk, the amount of IO doubles. Notice in the following output

that the disks were
completely idle waiting on IO. Even though requests were still being made (w/s), there was no disk activity and a large
discrepancy between the service time and average wait time. Also notice that the disks were 100% utilized even though
nothing was writing. This is indicative of a complete stall waiting for the volume group software to

catch up.
avg-cpu: %user %nice %sys %iowait %idle
0.00 0.00 1.00 52.68 46.32
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 0.00 0.00 11.00 0.00 0.00 0.00 0.00 0.00 145.44 5848.03 90.94 100.03
hdb 0.00 0.00 0.00 10.67 0.00 0.00 0.00 0.00 0.00 144.89 5872.97 93.78 100.03
md0 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
md1 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
avg-cpu: %user %nice %sys %iowait %idle
0.17 0.00 0.84 49.00 50.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hda 0.00 0.00 0.00 10.96 0.00 0.00 0.00 0.00 0.00 111.83 8053.45 90.94 99.70
hdb 0.00 0.00 0.00 10.96 0.00 0.00 0.00 0.00 0.00 111.28 8003.18 90.94 99.70
md0 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
md1 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
This behavior can also be observed using the sar b
command. This command shows IO statistics per device node

number. To locate the node numbers of your devices, use an ls command with a lL
switch.
# ls -lL /dev/md1
brw-rw---- 1 root disk 9, 1 Dec 30 08:13 /dev/md1
# ls -lL /dev/hda
brw-rw---- 1 root disk 3, 0 Dec 30 08:13 /dev/hda
# ls -lL /dev/hdb
brw-rw---- 1 root disk 3, 64 Dec 30 08:13 /dev/hdb
The mirror device has a major number of 9 and a minor number of 1 or 91.
The other two disks are 30
and 364.
Looking
at the sar output, it appears that the RAID device issues a large amount of IO writes to the

underlying drives. The drives end up timing out trying to process the requests.


# sar -b 3
<snip>
04:28:14 PM dev3-0 11.11 0.00 106650.51
04:28:14 PM dev3-64 10.10 0.00 106634.34
04:28:14 PM dev9-0 0.00 0.00 0.00
04:28:14 PM dev9-1 13326.26 0.00 106610.10
<snip>
04:28:15 PM dev3-0 9.90 0.00 0.00
04:28:15 PM dev3-64 10.89 0.00 0.00
04:28:15 PM dev9-0 0.00 0.00 0.00
04:28:15 PM dev9-1 0.00 0.00 0.00
<snip>
Condition 4: When Virtual Memory Kills IO
If the system does not have enough RAM to accommodate all requests, it must start to use the SWAP device. Just like file system IO, writes to the SWAP device are just as costly. If the system is extremely deprived of RAM, it is possible that it
will create a paging storm to the SWAP disk. If the SWAP device is on the same file system as the data trying to be
accessed, the system will enter into contention for the IO paths.

This will cause a complete performance breakdown on
the system. If pages can't be read or written to disk, they will stay in RAM longer. If they stay in RAM longer, the kernel will
need to free the RAM. The problem is that the IO channels are so clogged that nothing can be done.

This inevitably can
lead to a kernel panic and crash of the system.
The following vmstat output demonstrates a system under memory distress. It is writing data out to

the swap device:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
17 0 1250 3248 45820 1488472 30 132 992 0 2437 7657 23 50 0 23
11 0 1376 3256 45820 1488888 57 245 416 0 2391 7173 10 90 0 0
12 0 1582 1688 45828 1490228 63 131 1348 76 2432 7315 10 90 0 10
12 2 3981 1848 45468 1489824 185 56 2300 68 2478 9149 15 12 0 73
14 2 10385 2400 44484 1489732 0 87 1112 20 2515 11620 0 12 0 88
14 2 12671 2280 43644 1488816 76 51 1812 204 2546 11407 20 45 0 35

The previous output demonstrates a large amount of read requests into memory (bi).

The requests are so many that the
system is short on memory (free). This is causing the system to send blocks to the swap device (so)

and the size of swap keeps growing (swpd). Also notice a large percentage of WIO time (wa). This indicates that the CPU is starting to
slow because of IO requests.
To see the effect the swapping to disk is having on the system, check the swap partition on the drive using iostat.


# iostat -x 1

 

iostat --help:

 

                -c:     report percentage of time system has spent
                        in user/system/wait/idle mode
                -C:     report disk statistics by controller
                -d:     display disk Kb/sec, transfers/sec, avg.
                        service time in milliseconds
                -D:     display disk reads/sec, writes/sec,
                        percentage disk utilization
                -e:     report device error summary statistics
                -E:     report extended device error statistics
                -i:     show device IDs for -E output
                -I:     report the counts in each interval,
                        instead of rates, where applicable
                -l n:   Limit the number of disks to n
                -m:     Display mount points (most useful with -p)
                -M:     Display data throughput in MB/sec instead of Kb/sec
                -n:     convert device names to cXdYtZ format
                -p:     report per-partition disk statistics
                -P:     report per-partition disk statistics only,
                        no per-device disk statistics
                -r:     Display data in comma separated format
                -s:     Suppress state change messages
                -T  d|u  Display a timestamp in date (d) or unix time_t (u)
                -t:     display chars read/written to terminals
                -x:     display extended disk statistics
                -X:     display I/O path statistics
                -Y:     display I/O path (I/T/L) statistics
                -z:     Suppress entries with all zero values

avg-cpu: %user %nice %sys %idle
0.00 0.00 100.00 0.00
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/sda 0.00 1766.67 4866.67 1700.00 38933.33 31200.00 19466.67 15600.00 10.68 6526.67 100.56 5.08
3333.33
/dev/sda1 0.00 933.33 0.00 0.00 0.00 7733.33 0.00 3866.67 0.00 20.00 2145.07 7.37 200.00
/dev/sda2 0.00 0.00 4833.33 0.00 38666.67 533.33 19333.33 266.67 8.11 373.33 8.07 6.90 87.00
/dev/sda3 0.00 833.33 33.33 1700.00 266.67 22933.33 133.33 11466.67 13.38 6133.33 358.46 11.35
1966.67
In the previous example, both the swap device (/dev/sda1) and the file system device (/dev/sda3) are contending for
IO. Both have high amounts of write requests per second (w/s) and high wait time (await) to low

service time ratios
(svctm). This indicates that there is contention between the two partitions, causing both to under perform.
III. Tuning IO for Workloads
There are not many IO tuning parameters available for Linux. There are specific file system tuning parameters for each
file system. These have some impact on performance improvement. The hdparam command is also available to tune IDE
based disks. There are no specific SCSI/SAN tuning parameters available in stock Linux kernels although some patches
may exist if you wish to compile a custom kernel.
The key to tuning IO workloads is to understand your architecture and balance application workload appropriately across
systems. You must be able to identify which application is causing an IO bottleneck and then perform

the following tasks
in order:
1. Tune the application using any parameters available.
2. If there is contention between two file systems on the same disk, move one file system to another HBA and disk
drive/array.
3. Add more hardware to the system.
4. Migrate the application to another system, either virtual or hardware.

 

2016-11-10 19:13:22 github_25679381 阅读数 899

博客原文
安利一篇我翻译的国外大牛的神经网络入门文章

以一台测试机上的容器d-mcl-30_struc_test-n-2为例,容器id为373200daed7b,通过docker inspect可以看到如下信息:
这里写图片描述

图中高亮出来的部分是我们从宿主机映射到容器内的一个路径,下面我们来看这个路径对应的设备
这里写图片描述
通过下面的方法查看这个设备的真实路径(因为可能是一个软链接)
这里写图片描述

通过下面的方法查找挂载设备的设备号:
这里写图片描述

容器挂载路径disk设备的io可以通过监控下面的文件得到
这里写图片描述

这个文件记录的是当前这个容器在这个设备的写入/读取字节数,通过对这个文件的监控,取两次监控数值的差,然后除以取样间隔时长得到disk-iops

注意

如果通过nsenter命令进入一个容器采用dd命令进行磁盘读写测试,测试产生的读写是不会反应在这里说的文件上的。需要通过docker attach命令进入才可以

观察Linux 的性能

阅读数 1716

linux iotop安装

阅读数 1319

没有更多推荐了,返回首页