《Ourlinux》杂志

linux系统上可以使用（centos 2.6.18-144开始支持），dstat版本至少是：dstat-0.6.7-1.rf.noarch.rpm

安装

wget -c http://linux.web.psi.ch/dist/scientific/5/gfa/all/dstat-0.6.7-1.rf.noarch.rpm

rpm -Uvh dstat-0.6.7-1.rf.noarch.rpm

使用

# dstat -M topio -d -M topbio

—-most-expensive—- -dsk/total- —-most-expensive—-

i/o process      | read  writ|  block i/o process

owl_agent  9642B: 439B|  38k   42k|init       8317B:  41B

nginx         0 :2005B|   0    26k|

gmond         0 :  16k|   0    17k|

gmond         0 : 444B|   0     0 |

其他

低于这个kernel版本的可以参考这个方法：http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

最后多谢光哥和W总~

nmon for Linux 官方：http://nmon.sourceforge.net/pmwiki.php

下面是收集的资料：nmon工具介绍 (监控优化-操作系统监控)

原文：http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html
by VIVEK GITE

Need to monitor Linux server performance? Try these built-in command and a few add-on tools. Most Linux distributions are equipped with tons of monitoring. These tools provide metrics which can be used to get information about system activities. You can use these tools to find the possible causes of a performance problem. The commands discussed below are some of the most basic commands when it comes to system analysis and debugging server issues such as:

1. Finding out bottlenecks.
2. Disk (storage) bottlenecks.
3. CPU and memory bottlenecks.
4. Network bottlenecks.

#1: top - Process Activity Command

The top program provides a dynamic real-time view of a running system i.e. actual process activity. By default, it displays the most CPU-intensive tasks running on the server and updates the list every five seconds.

Commonly Used Hot Keys

The top command provides several useful hot keys:

Hot Key	Usage
t	Displays summary information off and on.
m	Displays memory information off and on.
A	Sorts the display by top consumers of various system resources. Useful for quick identification of performance-hungry tasks on a system.
f	Enters an interactive configuration screen for top. Helpful for setting up top for a specific task.
o	Enables you to interactively select the ordering within top.
r	Issues renice command.
k	Issues kill command.
z	Turn on or off color/mono

=> Related: How do I Find Out Linux CPU Utilization?

#2: vmstat - System Activity, Hardware and System Information

The command vmstat reports information about processes, memory, paging, block IO, traps, and cpu activity.
# vmstat 3
Sample Outputs:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 2540988 522188 5130400    0    0     2    32    4    2  4  1 96  0  0
 1  0      0 2540988 522188 5130400    0    0     0   720 1199  665  1  0 99  0  0
 0  0      0 2540956 522188 5130400    0    0     0     0 1151 1569  4  1 95  0  0
 0  0      0 2540956 522188 5130500    0    0     0     6 1117  439  1  0 99  0  0
 0  0      0 2540940 522188 5130512    0    0     0   536 1189  932  1  0 98  0  0
 0  0      0 2538444 522188 5130588    0    0     0     0 1187 1417  4  1 96  0  0
 0  0      0 2490060 522188 5130640    0    0     0    18 1253 1123  5  1 94  0  0

Display Memory Utilization Slabinfo

# vmstat -m

Get Information About Active / Inactive Memory Pages

# vmstat -a
=> Related: How do I find out Linux Resource utilization to detect system bottlenecks?

#3: w - Find Out Who Is Logged on And What They Are Doing

w command displays information about the users currently on the machine, and their processes.
# w username
# w vivek
Sample Outputs:

 17:58:47 up 5 days, 20:28,  2 users,  load average: 0.36, 0.26, 0.24
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    10.1.3.145       14:55    5.00s  0.04s  0.02s vim /etc/resolv.conf
root     pts/1    10.1.3.145       17:43    0.00s  0.03s  0.00s w

#4: uptime - Tell How Long The System Has Been Running

The uptime command can be used to see how long the server has been running. The current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes.
# uptime
Output:

 18:02:41 up 41 days, 23:42,  1 user,  load average: 0.00, 0.00, 0.00

1 can be considered as optimal load value. The load can change from system to system. For a single CPU system 1 - 3 and SMP systems 6-10 load value might be acceptable.

#5: ps - Displays The Processes

ps command will report a snapshot of the current processes. To select all processes use the -A or -e option:
# ps -A
Sample Outputs:

  PID TTY          TIME CMD
    1 ?        00:00:02 init
    2 ?        00:00:02 migration/0
    3 ?        00:00:01 ksoftirqd/0
    4 ?        00:00:00 watchdog/0
    5 ?        00:00:00 migration/1
    6 ?        00:00:15 ksoftirqd/1
....
.....
 4881 ?        00:53:28 java
 4885 tty1     00:00:00 mingetty
 4886 tty2     00:00:00 mingetty
 4887 tty3     00:00:00 mingetty
 4888 tty4     00:00:00 mingetty
 4891 tty5     00:00:00 mingetty
 4892 tty6     00:00:00 mingetty
 4893 ttyS1    00:00:00 agetty
12853 ?        00:00:00 cifsoplockd
12854 ?        00:00:00 cifsdnotifyd
14231 ?        00:10:34 lighttpd
14232 ?        00:00:00 php-cgi
54981 pts/0    00:00:00 vim
55465 ?        00:00:00 php-cgi
55546 ?        00:00:00 bind9-snmp-stat
55704 pts/1    00:00:00 ps

ps is just like top but provides more information.

Show Long Format Output

# ps -Al
To turn on extra full mode (it will show command line arguments passed to process):
# ps -AlF

To See Threads ( LWP and NLWP)

# ps -AlFH

To See Threads After Processes

# ps -AlLm

Print All Process On The Server

# ps ax
# ps axu

Print A Process Tree

# ps -ejH
# ps axjf
# pstree

Print Security Information

# ps -eo euser,ruser,suser,fuser,f,comm,label
# ps axZ
# ps -eM

See Every Process Running As User Vivek

# ps -U vivek -u vivek u

Set Output In a User-Defined Format

# ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
# ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
# ps -eopid,tt,user,fname,tmout,f,wchan

Display Only The Process IDs of Lighttpd

# ps -C lighttpd -o pid=
OR
# pgrep lighttpd
OR
# pgrep -u vivek php-cgi

Display The Name of PID 55977

# ps -p 55977 -o comm=

Find Out The Top 10 Memory Consuming Process

# ps -auxf | sort -nr -k 4 | head -10

Find Out top 10 CPU Consuming Process

# ps -auxf | sort -nr -k 3 | head -10

#6: free - Memory Usage

The command free displays the total amount of free and used physical and swap memory in the system, as well as the buffers used by the kernel.
# free
Sample Output:

            total       used       free     shared    buffers     cached
Mem:      12302896    9739664    2563232          0     523124    5154740
-/+ buffers/cache:    4061800    8241096
Swap:      1052248          0    1052248

=> Related: :

1. Linux Find Out Virtual Memory PAGESIZE
2. Linux Limit CPU Usage Per Process
3. How much RAM does my Ubuntu / Fedora Linux desktop PC have?

#7: iostat - Average CPU Load, Disk Activity

The command iostat report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS).
# iostat
Sample Outputs:

Linux 2.6.18-128.1.14.el5 (www03.nixcraft.in) 	06/26/2009

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.50    0.09    0.51    0.03    0.00   95.86

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              22.04        31.88       512.03   16193351  260102868
sda1              0.00         0.00         0.00       2166        180
sda2             22.04        31.87       512.03   16189010  260102688
sda3              0.00         0.00         0.00       1615          0

=> Related: : Linux Track NFS Directory / Disk I/O Stats

#8: sar - Collect and Report System Activity

The sar command is used to collect, report, and save system activity information. To see network counter, enter:
# sar -n DEV | more
To display the network counters from the 24th:
# sar -n DEV -f /var/log/sa/sa24 | more
You can also display real time usage using sar:
# sar 4 5
Sample Outputs:

Linux 2.6.18-128.1.14.el5 (www03.nixcraft.in) 		06/26/2009

06:45:12 PM       CPU     %user     %nice   %system   %iowait    %steal     %idle
06:45:16 PM       all      2.00      0.00      0.22      0.00      0.00     97.78
06:45:20 PM       all      2.07      0.00      0.38      0.03      0.00     97.52
06:45:24 PM       all      0.94      0.00      0.28      0.00      0.00     98.78
06:45:28 PM       all      1.56      0.00      0.22      0.00      0.00     98.22
06:45:32 PM       all      3.53      0.00      0.25      0.03      0.00     96.19
Average:          all      2.02      0.00      0.27      0.01      0.00     97.70

=> Related: : How to collect Linux system utilization data into a file

#9: mpstat - Multiprocessor Usage

The mpstat command displays activities for each available processor, processor 0 being the first one. mpstat -P ALL to display average CPU utilization per processor:
# mpstat -P ALL
Sample Output:

Linux 2.6.18-128.1.14.el5 (www03.nixcraft.in)	 	06/26/2009

06:48:11 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
06:48:11 PM  all    3.50    0.09    0.34    0.03    0.01    0.17    0.00   95.86   1218.04
06:48:11 PM    0    3.44    0.08    0.31    0.02    0.00    0.12    0.00   96.04   1000.31
06:48:11 PM    1    3.10    0.08    0.32    0.09    0.02    0.11    0.00   96.28     34.93
06:48:11 PM    2    4.16    0.11    0.36    0.02    0.00    0.11    0.00   95.25      0.00
06:48:11 PM    3    3.77    0.11    0.38    0.03    0.01    0.24    0.00   95.46     44.80
06:48:11 PM    4    2.96    0.07    0.29    0.04    0.02    0.10    0.00   96.52     25.91
06:48:11 PM    5    3.26    0.08    0.28    0.03    0.01    0.10    0.00   96.23     14.98
06:48:11 PM    6    4.00    0.10    0.34    0.01    0.00    0.13    0.00   95.42      3.75
06:48:11 PM    7    3.30    0.11    0.39    0.03    0.01    0.46    0.00   95.69     76.89

=> Related: : Linux display each multiple SMP CPU processors utilization individually.

#10: pmap - Process Memory Usage

The command pmap report memory map of a process. Use this command to find out causes of memory bottlenecks.
# pmap -d PID
To display process memory information for pid # 47394, enter:
# pmap -d 47394
Sample Outputs:

47394:   /usr/bin/php-cgi
Address           Kbytes Mode  Offset           Device    Mapping
0000000000400000    2584 r-x-- 0000000000000000 008:00002 php-cgi
0000000000886000     140 rw--- 0000000000286000 008:00002 php-cgi
00000000008a9000      52 rw--- 00000000008a9000 000:00000   [ anon ]
0000000000aa8000      76 rw--- 00000000002a8000 008:00002 php-cgi
000000000f678000    1980 rw--- 000000000f678000 000:00000   [ anon ]
000000314a600000     112 r-x-- 0000000000000000 008:00002 ld-2.5.so
000000314a81b000       4 r---- 000000000001b000 008:00002 ld-2.5.so
000000314a81c000       4 rw--- 000000000001c000 008:00002 ld-2.5.so
000000314aa00000    1328 r-x-- 0000000000000000 008:00002 libc-2.5.so
000000314ab4c000    2048 ----- 000000000014c000 008:00002 libc-2.5.so
.....
......
..
00002af8d48fd000       4 rw--- 0000000000006000 008:00002 xsl.so
00002af8d490c000      40 r-x-- 0000000000000000 008:00002 libnss_files-2.5.so
00002af8d4916000    2044 ----- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b15000       4 r---- 0000000000009000 008:00002 libnss_files-2.5.so
00002af8d4b16000       4 rw--- 000000000000a000 008:00002 libnss_files-2.5.so
00002af8d4b17000  768000 rw-s- 0000000000000000 000:00009 zero (deleted)
00007fffc95fe000      84 rw--- 00007ffffffea000 000:00000   [ stack ]
ffffffffff600000    8192 ----- 0000000000000000 000:00000   [ anon ]
mapped: 933712K    writeable/private: 4304K    shared: 768000K

The last line is very important:

• mapped: 933712K total amount of memory mapped to files
• writeable/private: 4304K the amount of private address space
• shared: 768000K the amount of address space this process is sharing with others

=> Related: : Linux find the memory used by a program / process using pmap command

#11 and #12: netstat and ss - Network Statistics

The command netstat displays network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. ss command is used to dump socket statistics. It allows showing information similar to netstat. See the following resources about ss and netstat commands:

• ss: Display Linux TCP / UDP Network and Socket Information
• Get Detailed Information About Particular IP address Connections Using netstat Command

#13: iptraf - Real-time Network Statistics

The iptraf command is interactive colorful IP LAN monitor. It is an ncurses-based IP LAN monitor that generates various network statistics including TCP info, UDP counts, ICMP and OSPF information, Ethernet load info, node stats, IP checksum errors, and others. It can provide the following info in easy to read format:

• Network traffic statistics by TCP connection
• IP traffic statistics by network interface
• Network traffic statistics by protocol
• Network traffic statistics by TCP/UDP port and by packet size
• Network traffic statistics by Layer2 address

#14: tcpdump - Detailed Network Traffic Analysis

The tcpdump is simple command that dump traffic on a network. However, you need good understanding of TCP/IP protocol to utilize this tool. For.e.g to display traffic info about DNS, enter:
# tcpdump -i eth1 'udp port 53'
To display all IPv4 HTTP packets to and from port 80, i.e. print only packets that contain data, not, for example, SYN and FIN packets and ACK-only packets, enter:
# tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)’
To display all FTP session to 202.54.1.5, enter:
# tcpdump -i eth1 'dst 202.54.1.5 and (port 21 or 20'
To display all HTTP session to 192.168.1.5:
# tcpdump -ni eth0 'dst 192.168.1.5 and tcp and port http'
Use wireshark to view detailed information about files, enter:
# tcpdump -n -i eth1 -s 0 -w output.txt src or dst port 80

#15: strace - System Calls

Trace system calls and signals. This is useful for debugging webserver and other server problems. See how to use to trace the process and see What it is doing.

#16: /Proc file system - Various Kernel Statistics

/proc file system provides detailed information about various hardware devices and other Linux kernel information. See Linux kernel /proc documentations for further details. Common /proc examples:
# cat /proc/cpuinfo
# cat /proc/meminfo
# cat /proc/zoneinfo
# cat /proc/mounts

17#: Nagios - Server And Network Monitoring

Nagios is a popular open source computer system and network monitoring application software. You can easily monitor all your hosts, network equipment and services. It can send alert when things go wrong and again when they get better. FAN is “Fully Automated Nagios”. FAN goals are to provide a Nagios installation including most tools provided by the Nagios Community. FAN provides a CDRom image in the standard ISO format, making it easy to easilly install a Nagios server. Added to this, a wide bunch of tools are including to the distribution, in order to improve the user experience around Nagios.

18#: Cacti - Web-based Monitoring Tool

Cacti is a complete network graphing solution designed to harness the power of RRDTool’s data storage and graphing functionality. Cacti provides a fast poller, advanced graph templating, multiple data acquisition methods, and user management features out of the box. All of this is wrapped in an intuitive, easy to use interface that makes sense for LAN-sized installations up to complex networks with hundreds of devices. It can provide data about network, CPU, memory, logged in users, Apache, DNS servers and much more. See how to install and configure Cacti network graphing tool under CentOS / RHEL.

#19: KDE System Guard - Real-time Systems Reporting and Graphing

KSysguard is a network enabled task and system monitor application for KDE desktop. This tool can be run over ssh session. It provides lots of features such as a client/server architecture that enables monitoring of local and remote hosts. The graphical front end uses so-called sensors to retrieve the information it displays. A sensor can return simple values or more complex information like tables. For each type of information, one or more displays are provided. Displays are organized in worksheets that can be saved and loaded independently from each other. So, KSysguard is not only a simple task manager but also a very powerful tool to control large server farms.

See the KSysguard handbook for detailed usage.

#20: Gnome System Monitor - Real-time Systems Reporting and Graphing

The System Monitor application enables you to display basic system information and monitor system processes, usage of system resources, and file systems. You can also use System Monitor to modify the behavior of your system. Although not as powerful as the KDE System Guard, it provides the basic information which may be useful for new users:

• Displays various basic information about the computer’s hardware and software.
• Linux Kernel version
• GNOME version
• Hardware
• Installed memory
• Processors and speeds
• System Status
• Currently available disk space
• Processes
• Memory and swap space
• Network usage
• File Systems
• Lists all mounted filesystems along with basic information about each.

Bounce: Additional Tools

A few more tools:

• nmap - scan your server for open ports.
• lsof - list open files, network connections and much more.
• ntop web based tool - ntop is the best tool to see network usage in a way similar to what top command does for processes i.e. it is network traffic monitoring software. You can see network status, protocol wise distribution of traffic for UDP, TCP, DNS, HTTP and other protocols.
• Conky - Another good monitoring tool for the X Window System. It is highly configurable and is able to monitor many system variables including the status of the CPU, memory, swap space, disk storage, temperatures, processes, network interfaces, battery power, system messages, e-mail inboxes etc.
• GKrellM - It can be used to monitor the status of CPUs, main memory, hard disks, network interfaces, local and remote mailboxes, and many other things.
• vnstat - vnStat is a console-based network traffic monitor. It keeps a log of hourly, daily and monthly network traffic for the selected interface(s).
• htop - htop is an enhanced version of top, the interactive process viewer, which can display the list of processes in a tree form.
• mtr - mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool.

Did I miss something? Please add your favorite system motoring tool in the comments.

朋友公司招聘PHP|Mysql|Linux人才：

要求：有对高负载站点的PHP开发、mysql管理、Linux系统管理、优化丰富经验即可！
PHP+mysql（1人）：2万月薪 + 干股
———— 或 —————–
php（1人）： 8K-10k月薪
mysql+sa（1人）：18K月薪

上班地点：上海陆家嘴软件园（东方路和峨山路口）

有兴趣的朋友，可以联系我gtalk：bixuan@gmail.com（邮件也可以） 或者QQ：6149968

网上其实有很多关于这方面的文章,那为什么还会有此篇呢,有这么几个原因,是我翻译的动力,

第一,概念和内容虽然老套,但都讲得很透彻,而且还很全面.

第二,理论结合实际,其中案例分析都不错.

第三,不花哨,采用的工具及命令都是最基本的,有助于实际操作.

但本人才疏学浅,译文大多数都是立足于自己对原文的理解,大家也可以自己去OSCAN上找原文,如果有什么较大出入,还望留言回复,甚是感激!

编者注：有什么问题可以联系本文译者Tonnyom[AT]hotmail.com 于2009.08.10翻译完毕，他的BLOG：http://tonnyom.yo2.cn或 http://www.sanotes.net

如果对本文编辑有什么问题和建议请联系我：bixuan@gmail.com http://www.ourlinux.net

下载地址：CHM文件 | ZIP文件 | PDF文件

感谢joe的分享，看到有位大牛做个针对进程统计IO情况的小工具，挺有意思。

1. 首先下载小工具：
   wget http://maatkit.googlecode.com/svn/trunk/util/iodump
   这个工具是perl写的。
2. 调整内核参数，打开kernel IO消息：
   echo 1 > /proc/sys/vm/block_dump
3. 直接执行如下脚本就可以看到结果了：
   while true; do sleep 1; dmesg -c; done | perl iodump
   注意稍等片刻按：ctrl+C退出，就可以看到结果了。

不过，压力大的话还是少玩，可能占用的资源比较多。

原文见：http://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/

Linux System and Performance Monitoring(总结篇)
Date: 2009.07.21
Author: Darren Hoch
译: Tonnyom[AT]hotmail.com

接前4篇：

Linux System and Performance Monitoring(CPU篇)

Linux System and Performance Monitoring(Memory篇)

Linux System and Performance Monitoring(I/O篇)

Linux System and Performance Monitoring(Network篇)

结束语: 这是该译文的最后一篇,在这篇中,作者提供了一个案例环境,用之前几篇所阐述的理论以及涉及到的工具,对其进行一个整体的系统性能检查.对大家更好理解系统性能监控,进行一次实战演习.
BTW:在中文技术网站上,类似内容的文章,大体是来自该作者06-07年所著论文,此译文是建立在作者为OSCON 2009重写基础上的.所以部分内容可能会存在重复雷同,特此说明下.

附录 A: 案例学习 - 性能监控之循序渐进

某一天,一个客户打电话来需要技术帮助,并抱怨平常15秒就可以打开的网页现在需要20分钟才可以打开.

具体系统配置如下:

RedHat Enterprise Linux 3 update 7
Dell 1850 Dual Core Xenon Processors, 2 GB RAM, 75GB 15K Drives
Custom LAMP software stack(译注:Llinux+apache+mysql+php 环境)

性能分析之步骤

1. 首先使用vmstat 查看大致的系统性能情况:

# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
1 0 249844 22488 18528 1218608 0 0 38656 0 1294 1034 17 7 58 18
0 1 249844 21228 18544 1219908 0 0 13696 484 609 559 5 3 54 38
0 1 249844 17752 18544 1223376 0 0 36224 4 1469 1035 10 6 67 17
1 1 249844 17856 18544 1208520 0 0 28724 0 950 941 33 12 49 7
1 0 249844 17748 18544 1222468 0 0 40968 8 1266 1164 17 9 59 16
1 0 249844 17912 18544 1222572 0 0 41344 12 1237 1080 13 8 65 13

分析:
1,不会是内存不足导致,因为swapping 始终没变化(si 和 so).尽管空闲内存不多(free),但swpd 也没有变化.
2,CPU 方面也没有太大问题,尽管有一些运行队列(procs r),但处理器还始终有50% 多的idle(CPU id).
3,有太多的上下文切换(cs)以及disk block从RAM中被读入(bo).
4,CPU 还有平均20% 的I/O 等待情况.

结论:
从以上总结出,这是一个I/O 瓶颈.

2. 然后使用iostat 检查是谁在发出IO 请求:

# iostat -x 1
Linux 2.4.21-40.ELsmp (mail.example.com) 03/26/2007

avg-cpu: %user %nice %sys %idle
30.00 0.00 9.33 60.67

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 7929.01 30.34 1180.91 14.23 7929.01 357.84 3964.50 178.92 6.93 0.39 0.03 0.06 6.69
/dev/sda1 2.67 5.46 0.40 1.76 24.62 57.77 12.31 28.88 38.11 0.06 2.78 1.77 0.38
/dev/sda2 0.00 0.30 0.07 0.02 0.57 2.57 0.29 1.28 32.86 0.00 3.81 2.64 0.03
/dev/sda3 7929.01 24.58 1180.44 12.45 7929.01 297.50 3964.50 148.75 6.90 0.32 0.03 0.06 6.68

avg-cpu: %user %nice %sys %idle
9.50 0.00 10.68 79.82

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 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86
/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 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/sda3 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86

avg-cpu: %user %nice %sys %idle
9.23 0.00 10.55 79.22

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 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51
/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 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/sda3 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51

分析:
1,看上去只有/dev/sda3 分区很活跃,其他分区都很空闲.
2,差不多有1200 读IOPS,磁盘本身是支持200 IOPS左右(译注:参考之前的IOPS 计算公式).
3,有超过2秒,实际上没有一个读磁盘(rkb/s).这和在vmstat 看到有大量I/O wait是有关系的.
4,大量的read IOPS(r/s)和在vmstat 中大量的上下文是匹配的.这说明很多读操作都是失败的.

结论:
从以上总结出,部分应用程序带来的读请求,已经超出了I/O 子系统可处理的范围.

3. 使用top 来查找系统最活跃的应用程序

# top -d 1
11:46:11 up 3 days, 19:13, 1 user, load average: 1.72, 1.87, 1.80
176 processes: 174 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 12.8% 0.0% 4.6% 0.2% 0.2% 18.7% 63.2%
cpu00 23.3% 0.0% 7.7% 0.0% 0.0% 36.8% 32.0%
cpu01 28.4% 0.0% 10.7% 0.0% 0.0% 38.2% 22.5%
cpu02 0.0% 0.0% 0.0% 0.9% 0.9% 0.0% 98.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
Mem: 2055244k av, 2032692k used, 22552k free, 0k shrd, 18256k buff
1216212k actv, 513216k in_d, 25520k in_c
Swap: 4192956k av, 249844k used, 3943112k free 1218304k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0

分析:
1,占用资源最多的好像就是mysql 进程,其他都处于完全idle 状态.
2,在top(wa) 看到的数值,和在vmstat 看到的wio 数值是有关联的.

结论:
从以上总结出,似乎就只有mysql 进程在请求资源,因此可以推论它就是导致问题的关键.

4. 现在已经确定是mysql 在发出读请求,使用strace 来检查它在读请求什么.

# strace -p 14939

Process 14939 attached - interrupt to quit
read(29, “\3\1\237\1\366\337\1\222%\4\2\0\0\0\0\0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “\1\1\241\366\337\1\223%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
_llseek(29, 2877621456, [2877621456], SEEK_SET) = 0
read(29, “\1\1\235\366\337\1\224%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 396) = 396
_llseek(29, 2877621872, [2877621872], SEEK_SET) = 0
read(29, “\1\1\245\366\337\1\225%\4\2\0\0\0\0\0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 404) = 404
_llseek(29, 2877622296, [2877622296], SEEK_SET) = 0
read(29, “\3\1\236\2\366\337\1\226%\4\2\0\0\0\0\0012P/d”, 20) = 20

分析:
1,大量的读操作都在不断寻道中,说明mysql 进程产生的是随机IO.
2,看上去似乎是,某一sql 查询导致读操作.

结论:
从以上总结出,所有的读IOPS 都是mysql 进程在执行某些读查询时产生的.

5. 使用mysqladmin 命令,来查找是哪个慢查询导致的.

# ./mysqladmin -pstrongmail processlist

+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist

分析:
1,MySQL 数据库里,似乎在不断的运行table update查询.
2,基于这个update 查询,数据库是对所有的table 进行索引.

结论:
从以上总结出,MySQL里这些update 查询问题,都是在尝试对所有table 进行索引.这些产生的读请求正是导致系统性能下降的原因.

后续

把以上这些性能信息移交给了相关开发人员,用于分析他们的PHP 代码.一个开发人员对代码进行了临时性优化.某个查询如果出错了,也最多到100K记录.数据库本身考虑最多存在4百万记录.最后,这个查询不会再给数据库带来负担了.

References
• Ezlot, Phillip – Optimizing Linux Performance, Prentice Hall, Princeton NJ 2005 ISBN – 0131486829
• Johnson, Sandra K., Huizenga, Gerrit – Performance Tuning for Linux Servers, IBM Press, Upper Saddle River NJ 2005 ISBN 013144753X
• Bovet, Daniel Cesati, Marco – Understanding the Linux Kernel, O’Reilly Media, Sebastoppl CA 2006, ISBN 0596005652
• Blum, Richard – Network Performance Open Source Toolkit, Wiley, Indianapolis IN 2003, ISBN 0-471-43301-2
• Understanding Virtual Memory in RedHat 4, Neil Horman, 12/05 http://people.redhat.com/nhorman/papers/rhel4_vm.pdf
• IBM, Inside the Linux Scheduler, http://www.ibm.com/developerworks/linux/library/l-scheduler/
• Aas, Josh, Understanding the Linux 2.6.8.1 CPU Scheduler, http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
• Wieers, Dag, Dstat: Versatile Resource Statistics Tool, http://dag.wieers.com/home-made/dstat/

上一篇：

Linux System and Performance Monitoring(Network篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/14/linux-system-and-performance-monitoring%E6%80%BB%E7%BB%93%E7%AF%87/

Linux System and Performance Monitoring(Network篇)
Date: 2009.07.21
Author: Darren Hoch
译: Tonnyom[AT]hotmail.com

接前3篇：

Linux System and Performance Monitoring(CPU篇)

Linux System and Performance Monitoring(Memory篇)

Linux System and Performance Monitoring(I/O篇)

8.0 Network 监控介绍

在所有的子系统监控中,网络是最困难的.这主要是由于网络概念很抽象.当监控系统上的网络性能,这有太多因素.这些因素包括了延迟,冲突,拥挤和数据包丢失.

这个章节讨论怎么样检查Ethernet(译注:网卡),IP,TCP的性能.

8.1 Ethernet Configuration Settings(译注:网卡配置的设置)

除非很明确的指定,几乎所有的网卡都是自适应网络速度.当一个网络中有很多不同的网络设备时,会各自采用不同的速率和工作模式.

多数商业网络都运行在100 或 1000BaseTX.使用ethtool 可以确定这个系统是处于那种速率.

以下的例子中,是一个有100BaseTX 网卡的系统,自动协商适应至10BaseTX 的情况.

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes

以下示范例子中,如何强制网卡速率调整至100BaseTX:

# ethtool -s eth0 speed 100 duplex full autoneg off

# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes

8.2 Monitoring Network Throughput(译注:网络吞吐量监控)

接口之间的同步并不意味着仅仅有带宽问题.重要的是,如何管理并优化,这2台主机之间的交换机,网线,或者路由器.测试网络吞吐量最好的方式就是,在这2个系统之间互相发送数据传输并统计下来,比如延迟和速度.

8.2.0 使用iptraf 查看本地吞吐量

iptraf 工具(http://iptraf.seul.org),提供了每个网卡吞吐量的仪表盘.

#iptraf -d eth0

Figure 1: Monitoring for Network Throughput

从输出中可看到,该系统发送传输率(译注:Outgoing rates)为 61 mbps,这对于100 mbps网络来说,有点慢.

8.2.1 使用netperf 查看终端吞吐量

不同于iptraf 被动的在本地监控流量,netperf 工具可以让管理员,执行更加可控的吞吐量监控.对于确定从客户端工作站到一个高负荷的服务器端(比如file 或web server),它们之间有多少吞吐量是非常有帮助的.netperf 工具运行的是client/server 模式.

完成一个基本可控吞吐量测试,首先netperf server 必须运行在服务器端系统上:

server# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

netperf 工具可能需要进行多重采样.多数基本测试就是一次标准的吞吐量测试.以下例子就是,一个LAN(译注:局域网) 环境下,从client 上执行一次30秒的TCP 吞吐量采样:

从输出可看出,该网络的吞吐量大致在89 mbps 左右.server(192.168.1.215) 与client 在同一LAN 中.这对于100 mbps网络来说,性能非常好.

client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.02 89.46

从LAN 切换到具备54G(译注:Wireless-G是未来54Mbps无线网联网标准)无线网络路由器中,并在10 英尺范围内测试时.该吞吐量就急剧的下降.在最大就为54 MBits的可能下,笔记本电脑可实现总吞吐量就为14 MBits.

client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.10 14.09

如果在50英尺范围内呢,则进一步会下降至5 MBits.

# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 30.64 5.05

如果从LAN 切换到互联网上,则吞吐量跌至1 Mbits下了.

# netperf -H litemail.org -p 1500 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
litemail.org (72.249.104.14 port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 31.58 0.93

最后是一个VPN 连接环境,这是所有网络环境中最槽糕的吞吐量了.

# netperf -H 10.0.1.129 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
10.0.1.129 (10.0.1.129) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

87380 16384 16384 31.99 0.51

另外,netperf 可以帮助测试每秒总计有多少的TCP 请求和响应数.通过建立单一TCP 连接并顺序地发送多个请求/响应(ack 包来回在1个byte 大小).有点类似于RDBMS 程序在执行多个交易或者邮件服务器在同一个连接管道中发送邮件.

以下例子在30 秒的持续时间内,模拟TCP 请求/响应:

client# netperf -t TCP_RR -H 192.168.1.230 -l 30
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to 192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 1 1 30.00 4453.80
16384 87380

在输出中看出,这个网络支持的处理速率为每秒4453 psh/ack(包大小为1 byte).这其实是理想状态下,因为实际情况时,多数requests(译注:请求),特别是responses(译注:响应),都大于1 byte.

现实情况下,netperf 一般requests 默认使用2K大小,responses 默认使用32K大小:

client# netperf -t TCP_RR -H 192.168.1.230 -l 30 — -r 2048,32768
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec

16384 87380 2048 32768 30.00 222.37
16384 87380

这个处理速率减少到了每秒222.

8.2.2 使用iperf 评估网络效率

基于都是需要在2端检查连接情况下,iperf 和netperf 很相似.不同的是,iperf 更深入的通过windows size和QOS 设备来检查TCP/UDP 的效率情况.这个工具,是给需要优化TCP/IP stacks以及测试这些stacks 效率的管理员们量身定做的.

iperf 作为一个二进制程序,可运行在server 或者client 任一模式下.默认使用50001 端口.

首先启动server 端(192.168.1.215):

server# iperf -s -D
Running Iperf Server as a daemon
The Iperf daemon process ID : 3655
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————

在以下例子里,一个无线网络环境下,其中client 端重复运行iperf,用于测试网络的吞吐量情况.这个环境假定处于被充分利用状态,很多主机都在下载ISO images文件.

首先client 端连接到server 端(192.168.1.215),并在总计60秒时间内,每5秒进行一次带宽测试的采样.

client# iperf -c 192.168.1.215 -t 60 -i 5
————————————————————
Client connecting to 192.168.1.215, TCP port 5001
TCP window size: 25.6 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 51978 connected with
192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 6.22 MBytes 10.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 5.0-10.0 sec 6.05 MBytes 10.1 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 10.0-15.0 sec 5.55 MBytes 9.32 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 15.0-20.0 sec 5.19 MBytes 8.70 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 20.0-25.0 sec 4.95 MBytes 8.30 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 25.0-30.0 sec 5.21 MBytes 8.74 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 30.0-35.0 sec 2.55 MBytes 4.29 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 35.0-40.0 sec 5.87 MBytes 9.84 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 40.0-45.0 sec 5.69 MBytes 9.54 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 45.0-50.0 sec 5.64 MBytes 9.46 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 50.0-55.0 sec 4.55 MBytes 7.64 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 55.0-60.0 sec 4.47 MBytes 7.50 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 61.9 MBytes 8.66 Mbits/sec

这台主机的其他网络传输,也会影响到这部分的带宽采样.所以可以看到总计60秒时间内,都在4 - 10 MBits 上下起伏.

除了TCP 测试之外,iperf 的UDP 测试主要是评估包丢失和抖动.

接下来的iperf 测试,是在同样的54Mbit G标准无线网络中.在早期的示范例子中,目前的吞吐量只有9 Mbits.

# iperf -c 192.168.1.215 -b 10M
WARNING: option -b implies udp testing
————————————————————
Client connecting to 192.168.1.215, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 107 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 33589 connected with 192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.8 MBytes 9.90 Mbits/sec
[ 3] Sent 8420 datagrams
[ 3] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 6.50 MBytes 5.45 Mbits/sec 0.480 ms 3784/ 8419 (45%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order

从输出中可看出,在尝试传输10M 的数据时,实际上只产生了5.45M.却有45% 的包丢失.

8.3 Individual Connections with tcptrace

tcptrace 工具提供了对于某一具体连接里,详细的TCP 相关信息.该工具使用libcap 来分析某一具体TCP sessions.该工具汇报的信息,有时很难在某一TCP stream被发现.这些信息

包括了有:

1,TCP Retransmissions(译注:IP 转播) - 所有数据大小被发送所需的包总额
2,TCP Windows Sizes - 连接速度慢与小的windows sizes 有关
3,Total throughput of the connection - 连接的吞吐量
4,Connection duration - 连接的持续时间

8.3.1 案例学习 - 使用tcptrace

tcptrace 工具可能已经在部分Linux 发布版中有安装包了,该文作者通过网站,下载的是源码安装包:http://dag.wieers.com/rpm/packages /tcptrace.tcptrace 需要libcap 基于文件输入方式使用.在tcptrace 没有选项的情况下,默认每个唯一的连接过程都将被捕获.

以下例子是,使用libcap 基于输入文件为bigstuff:

# tcptrace bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:01.634065, 89413 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
1: 192.168.1.60:pcanywherestat - 192.168.1.102:2571 (a2b) 404> 450< 2: 192.168.1.60:3356 - ftp.strongmail.net:21 (c2d) 35> 21< 3: 192.168.1.60:3825 - ftp.strongmail.net:65023 (e2f) 5> 4< (complete) 4: 192.168.1.102:1339 - 205.188.8.194:5190 (g2h) 6> 6< 5: 192.168.1.102:1490 - cs127.msg.mud.yahoo.com:5050 (i2j) 5> 5< 6: py-in-f111.google.com:993 - 192.168.1.102:3785 (k2l) 13> 14<

上面的输出中,每个连接都有对应的源主机和目的主机.tcptrace 使用-l 和-o 选项可查看某一连接更详细的数据.

以下的结果,就是在bigstuff 文件中,#16 连接的相关统计数据:

# tcptrace -l -o1 bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.529361, 276008 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
32 TCP connections traced:
TCP connection 1:
host a: 192.168.1.60:pcanywherestat
host b: 192.168.1.102:2571
complete conn: no (SYNs: 0) (FINs: 0)
first packet: Sun Jul 20 15:58:05.472983 2008
last packet: Sun Jul 20 16:00:04.564716 2008
elapsed time: 0:01:59.091733
total packets: 854
filename: bigstuff
a->b: b->a:
total packets: 404 total packets: 450
ack pkts sent: 404 ack pkts sent: 450
pure acks sent: 13 pure acks sent: 320
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 52608 unique bytes sent: 10624
actual data pkts: 391 actual data pkts: 130
actual data bytes: 52608 actual data bytes: 10624
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 391 pushed data pkts: 130
SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 0 bytes mss requested: 0 bytes
max segm size: 560 bytes max segm size: 176 bytes
min segm size: 48 bytes min segm size: 80 bytes
avg segm size: 134 bytes avg segm size: 81 bytes
max win adv: 19584 bytes max win adv: 65535 bytes
min win adv: 19584 bytes min win adv: 64287 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 19584 bytes avg win adv: 64949 bytes
initial window: 160 bytes initial window: 0 bytes
initial window: 2 pkts initial window: 0 pkts
ttl stream length: NA ttl stream length: NA
missed data: NA missed data: NA
truncated data: 36186 bytes truncated data: 5164 bytes
truncated packets: 391 pkts truncated packets: 130 pkts
data xmit time: 119.092 secs data xmit time: 116.954 secs
idletime max: 441267.1 ms idletime max: 441506.3 ms
throughput: 442 Bps throughput: 89 Bps

8.3.2 案例学习 - 计算转播率

几乎不可能确定说哪个连接会有严重不足的转播问题,只是需要分析,使用tcptrace 工具可以通过过滤机制和布尔表达式来找出出问题的连接.一个很繁忙的网络中,会有很多的连接,几乎所有的连接都会有转播.找出其中最多的一个,这就是问题的关键.

下面的例子里,tcptrace 将找出那些转播大于100 segments(译注:分段数)的连接:

# tcptrace -f’rexmit_segs>100′ bigstuff
Output filter: ((c_rexmit_segs>100)OR(s_rexmit_segs>100))
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004

146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.687788, 212431 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
16: ftp.strongmail.net:65014 - 192.168.1.60:2158 (ae2af) 18695> 9817< 在这个输出中,是#16 这个连接里,超过了100 转播.现在,使用以下命令查看关于这个连接的其他信息: # tcptrace -l -o16 bigstuff arg remaining, starting with ‘bigstuff’ Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004 146108 packets seen, 145992 TCP packets traced elapsed wallclock time: 0:00:01.355964, 107752 pkts/sec analyzed trace file elapsed time: 0:09:20.358860 TCP connection info: 32 TCP connections traced: ================================ TCP connection 16: host ae: ftp.strongmail.net:65014 host af: 192.168.1.60:2158 complete conn: no (SYNs: 0) (FINs: 1) first packet: Sun Jul 20 16:04:33.257606 2008 last packet: Sun Jul 20 16:07:22.317987 2008 elapsed time: 0:02:49.060381 total packets: 28512 filename: bigstuff ae->af: af->ae:

unique bytes sent: 25534744 unique bytes sent: 0
actual data pkts: 18695 actual data pkts: 0
actual data bytes: 25556632 actual data bytes: 0
rexmt data pkts: 1605 rexmt data pkts: 0
rexmt data bytes: 2188780 rexmt data bytes: 0

计算转播率:
rexmt/actual * 100 = Retransmission rate

1605/18695* 100 = 8.5%

这个慢连接的原因,就是因为它有8.5% 的转播率.

8.3.3 案例学习 - 计算转播时间

tcptrace 工具有一系列的模块展示不同的数据,按照属性,其中就有protocol(译注:协议),port(译注:端口),time等等.Slice module使得你可观察在一段时间内的TCP 性能.你可以在一系列的转发过程中,查看其他性能数据,以确定找出瓶颈.

以下例子示范了,tcptrace 是怎样使用slice 模式的:

# tcptrace –xslice bigfile

以上命令会创建一个slice.dat 文件在现在的工作目录中.这个文件内容,包含是每15秒间隔内转播的相关信息:

# ls -l slice.dat
-rw-r–r– 1 root root 3430 Jul 10 22:50 slice.dat
# more slice.dat
date segs bytes rexsegs rexbytes new active
————— ——– ——– ——– ——– ——– ——–
22:19:41.913288 46 5672 0 0 1 1
22:19:56.913288 131 25688 0 0 0 1
22:20:11.913288 0 0 0 0 0 0
22:20:26.913288 5975 4871128 0 0 0 1
22:20:41.913288 31049 25307256 0 0 0 1
22:20:56.913288 23077 19123956 40 59452 0 1
22:21:11.913288 26357 21624373 5 7500 0 1
22:21:26.913288 20975 17248491 3 4500 12 13
22:21:41.913288 24234 19849503 10 15000 3 5
22:21:56.913288 27090 22269230 36 53999 0 2
22:22:11.913288 22295 18315923 9 12856 0 2
22:22:26.913288 8858 7304603 3 4500 0 1

8.4 结论

监控网络性能由以下几个部分组成:

1,检查并确定所有网卡都工作在正确的速率.
2,检查每块网卡的吞吐量,并确认其处于服务时的网络速度.
3,监控网络流量的类型,并确定适当的流量优先级策略.

上一篇：

Linux System and Performance Monitoring(I/O篇)

下一篇：

Linux System and Performance Monitoring(总结篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/13/linux-system-and-performance-monitoringnetwork%E7%AF%87/

Linux System and Performance Monitoring(I/O篇)
Date:         2009.07.21
Author:       Darren Hoch
译:           Tonnyom[AT]hotmail.com

接上两篇：

Linux System and Performance Monitoring(CPU篇)

Linux System and Performance Monitoring(Memory篇)

6.0 I/O 监控介绍

磁盘I/O 子系统是Linux 系统中最慢的部分.这个主要是归于CPU到物理操作磁盘之间距离(译注:盘片旋转以及寻道).如果拿读取磁盘和内存的时间作比较就是分钟级到秒级,这就像7天和7分钟的区别.因此本质上,Linux 内核就是要最低程度的降低I/O 数.本章将诉述内核在磁盘和内存之间处理数据的这个过程中,哪些地方会产生I/O.
6.1 读和写数据 - 内存页

Linux 内核将硬盘I/O 进行分页,多数Linux 系统的默认页大小为4K.读和写磁盘块进出到内存都为4K 页大小.你可以使用time 这个命令加-v 参数,来检查你系统中设置的页大小:

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

6.2 Major and Minor Page Faults(译注:主要页错误和次要页错误)

Linux,类似多数的UNIX 系统,使用一个虚拟内存层来映射硬件地址空间.当一个进程被启动,内核先扫描CPU caches和物理内存.如果进程需要的数据在这2个地方都没找到,就需要从磁盘上读取,此时内核过程就是major page fault(MPF).MPF 要求磁盘子系统检索页并缓存进RAM.

一旦内存页被映射进内存的buffer cache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minor page fault(MnPF).与在磁盘上操作相比,MnPF 通过反复使用内存中的内存页就大大的缩短了内核时间.

以下的例子,使用time 命令验证了,当进程启动后,MPF 和 MnPF 的变化情况.第一次运行进程,MPF 会更多:

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

第二次再运行时,内核已经不需要进行MPF了,因为进程所需的数据已经在内存中:

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

6.3 The File Buffer Cache(译注:文件缓存区)

文件缓存区就是指,内核将MPF 过程最小化,MnPF 过程最大化.随着系统不断的产生I/O,buffer cache也将不断的增加.直到内存不够,以及系统需要释放老的内存页去给其他用户进程使用时,系统就会丢弃这些内存页.结果是,很多sa(译注:系统管理员)对系统中过少的free memory(译注:空闲内存)表示担心,实际上这是系统更高效的在使用caches.

以下例子,是查看/proc/meminfo 文件:

# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
<snip>

可以看出,这个系统总计有2GB (Memtotal)的可用内存.当前的空闲内存为52MB (MemFree),有24 MB内存被分配磁盘写操作(Buffers),还有1.7 GB页用于读磁盘(Cached).

内核这样是通过MnPF机制,而不代表所有的页都是来自磁盘.通过以上部分,我们不可能确认系统是否处于瓶颈中.

6.4 Type of Memory Pages

在Linux 内核中,memory pages有3种,分别是:

1,Read Pages - 这些页通过MPF 从磁盘中读入,而且是只读.这些页存在于Buffer Cache中以及包括不能够修改的静态文件,二进制文件,还有库文件.当内核需要它们时,将读取到内存中.如果内存不足,内核将释放它们回空闲列表中.程序再次请求时,则通过MPF 再次读回内存.

2,Dirty Pages - 这些页是内核在内存中已经被修改过的数据页.当这些页需要同步回磁盘上,由pdflush 负责写回磁盘.如果内存不足,kswapd (与pdflush 一起)将这些页写回到磁盘上并释放更多的内存.

3,Anonymous Pages - 这些页属于某个进程,但是没有任何磁盘文件和它们有关.他们不能和同步回磁盘.如果内存不足,kswapd 将他们写入swap 分区上并释放更多的内存(”swapping” pages).

6.5 Writing Data Pages Back to Disk

应用程序有很多选择可以写脏页回磁盘上,可通过I/O 调度器使用 fsync() 或 sync() 这样的系统函数来实现立即写回.如果应用程序没有调用以上函数,pdflush 进程会定期与磁盘进行同步.

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

7.0 监控 I/O

当觉得系统中出现了I/O 瓶颈时,可以使用标准的监控软件来查找原因.这些工具包括了top,vmstat,iostat,sar.它们的输出结果一小部分是很相似,不过每个也都提供了各自对于性能不同方面的解释.以下章节就将讨论哪些情况会导致I/O 瓶颈的出现.

7.1 Calculating IO’s Per Second(译注:IOPS 的计算)

每个I/O 请求到磁盘都需要若干时间.主要是因为磁盘的盘边必须旋转,机头必须寻道.磁盘的旋转常常被称为”rotational delay”(RD),机头的移动称为”disk seek”(DS).一个I/O 请求所需的时间计算就是DS加上RD.磁盘的RD 基于设备自身RPM 单位值(译注:RPM 是Revolutions Perminute的缩写,是转/每分钟,代表了硬盘的转速).一个RD 就是一个盘片旋转的

半圆.如何计算一个10K RPM设备的RD 值呢:

1, 10000 RPM / 60 seconds (10000/60 = 166 RPS)
2, 转换为 166分之1 的值(1/166 = 0.006 seconds/Rotation)
3, 单位转换为毫秒(6 MS/Rotation)
4, 旋转半圆的时间(6/2 = 3MS) 也就是 RD
5, 加上平均3 MS 的寻道时间 (3MS + 3MS = 6MS)
6, 加上2MS 的延迟(6MS + 2MS = 8MS)
7, 1000 MS / 8 MS (1000/8 = 125 IOPS)

每次应用程序产生一个I/O,在10K RPM磁盘上都要花费平均 8MS.在这个固定时间里,磁盘将尽可能且有效率在进行读写磁盘.IOPS 可以计算出大致的I/O 请求数,10K RPM 磁盘有能力提供120-150 次IOPS.评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出.

7.2 Random vs Sequential I/O(译注:随机/顺序 I/O)

per I/O产生的KB 字节数是与系统本身workload相关的,有2种不同workload的类型,它们是sequential和random.

7.2.1 Sequential I/O(译注:顺序IO)

iostat 命令提供信息包括IOPS 和每个I/O 数据处理的总额.可使用iostat -x 查看.顺序的workload是同时读顺序请求大量的数据.这包括的应用,比如有商业数据库(database)在执行大量的查询和流媒体服务.在这个workload 中,KB per I/O 的比率应该是很高的.Sequential workload 是可以同时很快的移动大量数据.如果每个I/O 都节省了时间,那就意味了能带来更多的数据处理.

# iostat -x 1

avg-cpu: %user   %nice   %sys    %idle
0.00      0.00    57.1 4  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 1  06080.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   594.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    952.94    0.00   1976.47  0.00     165.59   0.00    0.00   276.47

评估IOPS 的效能,可用每秒读写I/O 字节数除以每秒读写IOPS 数得出,比如
rkB/s  除以 r/s
wkB/s  除以 w/s

53040/105 = 505KB per I/O
71152/102 = 697KB per I/O
在上面例子可看出,每次循环下,/dev/sda 的per I/O 都在增加.

7.2.2 Random I/O(译注:随机IO)

Random的worklaod环境下,不依赖于数据大小的多少,更多依赖的是磁盘的IOPS 数.Web和Mail 服务就是典型的Random workload.I/O 请求内容都很小.Random workload是同时每秒会有更多的请求数产生.所以,磁盘的IOPS 数是关键.

# 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

计算方式和之前的公式一致:

2640/102 = 23KB per I/O
3176/130 = 24KB per I/O

(译注:对于顺序I/O来说,主要是考虑读取大量数据的能力即KB per request.对于随机I/O系统,更需要考虑的是IOPS值)

7.3 When Virtual Memory Kills I/O

如果系统没有足够的RAM 响应所有的请求,就会使用到SWAP device.就像使用文件系统I/O,使用SWAP device 代价也很大.如果系统已经没有物理内存可用,那就都在SWAP disk上创建很多很多的内存分页,如果同一文件系统的数据都在尝试访问SWAP device,那系统将遇到I/O 瓶颈.最终导致系统性能的全面崩溃.如果内存页不能够及时读或写磁盘,它们就一直保留在RAM中.如果保留时间太久,内核又必须释放内存空间.问题来了,I/O 操作都被阻塞住了,什么都没做就被结束了,不可避免地就出现kernel panic和system crash.

下面的vmstat 示范了一个内存不足情况下的系统:

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

这个结果可看出,大量的读请求回内存(bi),导致了空闲内存在不断的减少(free).这就使得系统写入swap device的块数目(so)和swap 空间(swpd)在不断增加.同时看到CPU WIO time(wa)百分比很大.这表明I/O 请求已经导致CPU 开始效率低下.

要看swaping 对磁盘的影响,可使用iostat 检查swap 分区

# iostat -x 1

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

在这个例子中,swap device(/dev/sda1) 和 file system device(/dev/sda3)在互相作用于I/O. 其中任一个会有很高写请求(w/s),也会有很高wait time(await),或者较低的服务时间比率(svctm).这表明2个分区之间互有联系,互有影响.

7.4 结论

I/O 性能监控包含了以下几点:

1,当CPU 有等待I/O 情况时,那说明磁盘处于超负荷状态.
2,计算你的磁盘能够承受多大的IOPS 数.
3,确定你的应用是属于随机或者顺序读取磁盘.
4,监控磁盘慢需要比较wait time(await) 和 service time(svctm).
5,监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

上一篇：

Linux System and Performance Monitoring(Memory篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/12/linux-system-and-performance-monitoringio篇/

Linux System and Performance Monitoring(Memory篇)
Date:       2009.07.21
Author: Darren Hoch
译:            Tonnyom[AT]hotmail.com

本文接上一篇：

Linux System and Performance Monitoring(CPU篇)

5.0 Virtual Memory介绍

虚拟内存就是采用硬盘对物理内存进行扩展,所以对可用内存的增加是要相对在一个有效范围内的.内核会写当前未使用内存块的内容到硬盘上,此时这部分内存被用于其它用途.当再一次需要原始内容时,此时再读回到内存中.这对于用户来说,是完全透明的;在Linux 下运行的程序能够看到,也仅仅是大量的可用内存,同时也不会留意到,偶尔还有部分是驻留在磁盘上的.当然,在硬盘上进行读和写,都是很慢的(大约会慢上千倍),相对于使用真实内存的话,因此程序无法运行的更快.用硬盘的一部分作为Virtual Memory,这就被称为”swap space”(译注:交换空间).

5.1 Virtual Memory Pages

虚拟内存被分为很多 pages(译注:页),在X86架构中,每个虚拟内存页为 4KB.当内核写内存到磁盘或者读磁盘到内存,这就是一次写内存到页的过程.内核通常是在swap 分区和文件系统之间进行这样的操作.

5.2 Kernel Memory Paging

内存分页在正常情况下总是活跃的,与memory swapping(译注:内存交换)之间不要搞错了.内存分页是指内核会定期将内存中的数据同步到硬盘,这个过程就是Memory Paging.日复一日,应用最终将会消耗掉所有的内存空间.考虑到这点,内核就必须经常扫描内存空间并且收回其中未被使用的内存页,然后再重新分配内存空间给其他应用使用.

5.3 The Page Frame Reclaim Algorithm(PFRA)(译注:页框回收算法)

PFRA 就是OS 内核用来回收并释放内存空间的算法.PFRA 选择哪个内存页被释放是基于内存页类型的.页类型有以下几种:

Unreclaimable –锁定的，内核保留的页面
Swappable –匿名的内存页
Syncable –通过硬盘文件备份的内存页
Discardable –静态页和被丢弃的页

除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收.

与PFRA 相关的,还包括kswapd 内核线程以及Low On Memory Reclaiming(LMR算法) 这2种进程和实现.

5.4 kswapd

kswapd 进程负责确保内存空间总是在被释放中.它监控内核中的pages_high和pages_low阀值.如果空闲内存的数值低于 pages_low,则每次 kswapd 进程启动扫描并尝试释放32个free pages.并一直重复这个过程,直到空闲内存的数值高于 pages_high.

kswapd 进程完成以下几个操作:

1,如果该页处于未修改状态,则将该页放置回空闲列表中.
2,如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘.
3,如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swap device.

# ps -ef | grep kswapd
root 30 1 0 23:01 ? 00:00:00 [kswapd0]

5.5 Kernel Paging with pdflush

pdflush 进程负责将内存中的内容和文件系统进行同步操作.也就是说,当一个文件在内存中进行修改后, pdflush 将负责写回到磁盘上.

# ps -ef | grep pdflush
root 28 3 0 23:01 ? 00:00:00 [pdflush]
root 29 3 0 23:01 ? 00:00:00 [pdflush]

当内存中存在10% 的脏页,pdflush 将被启动同步脏页回文件系统里.这个参数值可以通过 vm.dirty_background_ratio 来进行调整.

(译注:
Q:什么是脏页?
A:由于内存中页缓存的缓存作用,写操作实际上都是延迟的.当页缓存中的数据比磁盘存储的数据还要更新时,那么该数据就被称做脏页.)

# sysctl -n vm.dirty_background_ratio
10

在多数环境下,Pdflush与PFRA是独立运行的,当内核调用LMR时,LMR 就触发pdflush将脏页写入到磁盘里.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
在2.4 内核下,一个高负荷的内存环境中,系统将遇到交换过程中不断的崩溃.这是因为PFRA 从一个运行进程中,偷取其中一个内存页并尝试使用.导致结果就是,这个进程如果要回收那个页时,要是没有就会尝试再去偷取这个页,这样一来,就越来越糟糕了.在2.6 内核下,使用”Swap token”修复了这个BUG,用来防止PFRA 不断从一个进程获取同一个页.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5.6 案例学习:大量的入口I/O

vmstat 工具报告里除了CPU 使用情况,还包括了虚拟内存.以下就是vmstat 输出中关于虚拟内存的部分:

Table 2: The vmstat Memory Statistics
Field Description
Swapd The amount of virtual memory in KB currently in use. As free memory reaches low thresholds, more data is paged to the swap device.
当前虚拟内存使用的总额(单位:KB).空闲内存达到最低的阀值时,更多的数据被转换成页到交换设备中.
Free The amount of physical RAM in kilobytes currently available to running applications.
当前内存中可用空间字节数.
Buff The amount of physical memory in kilobytes in the buffer cache as a result of read() and write() operations.
当前内存中用于read()和write()操作的缓冲区中缓存字节数
Cache The amount of physical memory in kilobytes mapped into process address space.
当前内存中映射到进程地址空间字节数
So The amount of data in kilobytes written to the swap disk.
写入交换空间的字节数总额
Si The amount of data in kilobytes written from the swap disk back into RAM.
从交换空间写回内存的字节数总额
Bo The amount of disk blocks paged out from the RAM to the filesystem or swap device.
磁盘块页面从内存到文件或交换设备的总额
Bi The amount of disk blocks paged into RAM from the filesystem or swap device.
磁盘块页面从文件或交换设备到内存的总额

以下 vmstat 的输出结果,就是演示一个在I/O 应用中,虚拟内存在高负荷情况下的环境

# vmstat 3
procs                               memory                swap       io          system cpu
r  b  swpd       free       buff      cache       si     so  bi      bo   in    cs  us  sy id wa
3 2 809192 261556 79760 886880 416 0 8244 751 426 863 17 3 6 75
0 3 809188 194916 79820 952900 307 0 21745 1005 1189 2590 34 6 12 48
0 3 809188 162212 79840 988920 95 0 12107 0 1801 2633 2 2 3 94
1 3 809268 88756 79924 1061424 260 28 18377 113 1142 1694 3 5 3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9 12 61
2 1 854780 17688 34140 1208980 1 9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31 4384 16524 27808 1490 1634 41 10 7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337 678 932 33 7 3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982 40 12 2 46
5 2 900472 17980 32440 1253884 24 4851 17521 4856 934 1730 48 12 13 26
1 1 904404 17620 32492 1258928 15 1316 7647 15804 919 978 49 9 17 25
4 1 911192 17944 32540 1266724 37 2263 12907 3547 834 1421 47 14 20 20
1 1 919292 17876 31824 1275832 1 2745 16327 2747 617 1421 52 11 23 14
5 0 925216 17812 25008 1289320 12 1975 12760 3181 772 1254 50 10 21 19
0 5 932860 17736 21760 1300280 8 2556 15469 3873 825 1258 49 13 24 15

根据观察值,我们可以得到以下结论:

1,大量的disk pages(bi)被写入内存,很明显在进程地址空间里,数据缓存(cache)也在不断的增长.

2,在这个时间点上,空闲内存(free) 始终保持在17MB,即使数据从硬盘读入而在消耗RAM.

3,为了维护空闲列表, kswapd 从读/写缓存区(buff)中获取内存并分配到空闲列表里.很明显可以看到buffer cache(buff) 在逐渐的减少中.

4, 同时kswapd 进程不断的写脏页到swap device(so)时,很明显虚拟内存的利用率是在逐渐的增加中(swpd).

5.7 结论

监控虚拟内存性能由以下几个部分组成:

1,当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).

2,较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.

3,如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.

上一篇：

Linux System and Performance Monitoring(CPU篇)

下一篇：

Linux System and Performance Monitoring(I/O篇)

同事力作，原文见：http://tonnyom.yo2.cn/2009/08/11/linux-system-and-performance-monitoringmemory篇/