【转】Linux服务器性能评估与优化(一)

 

转自：https://blog.csdn.net/hguisu/article/details/39373311

 

1、前言简介

---

1.1、影响Linux服务器性能的因素 

  1. 操作系统级

        性能调优是找出系统瓶颈并消除这些瓶颈的过程。 很多系统管理员认为性能调优仅仅是调整一下内核的参数即可解决问题， 事实上情况并不是这样。 性能调优是实现操作系统的各个子系统之间的平衡性，这些子系统包括：

Ø       CPU

Ø       内存

Ø       磁盘I/O带宽

Ø       网络I/O带宽

子系统之间相互依存，任何一个子系统的负载过度都能导致其他子系统出现问题，例如：
* 大量的 page-in IO 请求可能导致内存队列被塞满
* 网卡的巨量吞吐可能导致 CPU 资源耗尽
* 系统尝试保持释放内存队列时可能耗尽 CPU 资源
* 来自内存的大量磁盘写入请求可能导致 CPU 资源和 IO 通道耗尽

性能调优的前提是找出系统瓶颈之所在， 尽管问题看似由某个子系统所导致， 然而这很可能是另外一个子系统的过载所引起的。

2.    程序应用级

 为了明白从何处开始着手调整性能瓶颈， 弄清被分析系统的性能表现是首要任务。 任何系统的应用常可分为以下两类：
1） IO 限制型——一个 IO 限制型的应用需要大量的内存和基础存储设备占用。 因其需要大量的数据读写请求，此类应用对 CPU 和网络需求不高（除非存储系统在网络上） 。
       IO 限制型应用使用 CPU 资源来进行 IO 操作且常进入睡眠状态。 数据库应用常被认为属于此类。

2）CPU 限制型——一个 CPU 限制型应用需要大量的 CPU 资源，来进行批量的处理或大量的计算。大容量 web 服务，mail 服务，以及任何类型的渲染服务都被归到此类。

1.2、系统性能评估标准

        判断一个系统是否有性能问题的唯一途径是弄清楚对系统的期望是神马， 需求的性能是神马， 应该得到的数据是神马？而为了建立这些信息的唯一途径是为系统建立一个基准。 在性能可接受的状态下必须为系统建立统计信息，这样就可以在性能不可接受时进行对比。

影响性能因素	评判标准
	好	坏	糟糕
CPU	user% + sys%< 70%	user% + sys%= 85%	user% + sys% >=90%
内存	Swap In（si）＝0 Swap Out（so）＝0	Per CPU with 10 page/s	More Swap In & Swap Out
磁盘	iowait % < 20%	iowait % =35%	iowait % >= 50%

 

其中：

       %user：表示CPU处在用户模式下的时间百分比。

       %sys：表示CPU处在系统模式下的时间百分比。

       %iowait：表示CPU等待输入输出完成时间的百分比。

       swap in：即si，表示虚拟内存的页导入，即从SWAP DISK交换到RAM

       swap out：即so，表示虚拟内存的页导出，即从RAM交换到SWAP DISK。

 

1.3、系统性能分析工具

1.常用系统命令 

Vmstat、sar、iostat、netstat、free、ps、top等

 

2.常用组合方式 

•           用vmstat、sar、iostat检测是否是CPU瓶颈

•           用free、vmstat检测是否是内存瓶颈

•           用iostat检测是否是磁盘I/O瓶颈

•           用netstat检测是否是网络带宽瓶颈(netstat -nat | awk ‘FNR>2{print $NF}’ | sort | uniq -c) 

             netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

 

Linux性能评估与优化：

      cpu，内存，IO, 网络

 

 

 

2、负载：整体性能评估

---

2.1系统整体性能评估（uptime命令/top）

 

[root@web1 ~]# uptime

16:38:00 up 118 days,  3:01,  5 users,  load average: 1.22, 1.02, 0.91

这里需要注意的是：load average这个输出值，这三个值的大小一般不能大于系统CPU的个数，例如，本输出中系统有8个CPU,如果load average的三个值长期大于8时，说明CPU很繁忙，负载很高，可能会影响系统性能，但是偶尔大于8时，倒不用担心，一般不会影响系统性能。相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲的时间片，比如本例中的输出，CPU是非常空闲的。

 

 

Load：top

系统负载指运行队列的平均长度，也就是等待CPU的平均进程数。Load越高说明系统响应越慢，如果load是0，代表进程不需要等待，立刻就能获得cpu运行。可以通过查询文件/proc/loadavg获取系统在前一分钟、前五分钟和前十五分钟的平均负载以及当前运行的进程、系统的进程数和上一次调度运行的进程。

justin@junjun:/proc$ cat/proc/loadavg

0.71 0.70 0.63 1/403 5111

在linux系统中，也可直接通过命令行 “w”或者“uptime”查看，如下：

16:10:22 up 1 day, 4:18,  3 users,  load average: 0.34, 0.50, 0.52

USER     TTY      FROM              LOGIN@  IDLE   JCPU   PCPU WHAT

justin   tty7     :0               Tue11   28:19m 10:15   0.22s gnome-session

justin   pts/0    :0.0             Tue11   28:17m 2:22   0.00s /bin/bash./jettyctl.sh

justin   pts/1    :0.0             16:08    0.00s 0.17s  0.00s w

cpu usage：

系统的CPU使用率。

可以用“top”命令动态的显示当前系统进程用户的使用情况。

前五行是系统整体的统计信息。

第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：当前时间；系统运行时间，格式为时:分；当前登录用户数；系统负载，即任务队列的平均长度。

第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。

内容如下：Tasks: 175 total进程总数；1 running正在运行的进程数；174 sleeping睡眠的进程数；0 stopped停止的进程数；0 zombie僵尸进程数

Cpu(s):22.0% us用户空间占用CPU百分比

20.7%sy内核空间占用CPU百分比

1.1%ni用户进程空间内改变过优先级的进程占用CPU百分比

52.7%id空闲CPU百分比

3.3%wa等待输入输出的CPU时间百分比

0.0%hi

0.2%si swap in，表示虚拟内存的页导入，即从SWAPDISK交换到RAM

0.0%st swap out，表示虚拟内存的页导出，即从RAM交换到SWAPDISK。

 

PR：操作系统给进程的安排的优先级。这个值标示进程调度器分配给进程的时间片长度。单位是时钟个数。如果一个Linux系统的时间片是10ms，那么PID是2718的进程在执行了200ms后，才会进行进程切换。 

RES：进程占用的物理内存大小             

VIRT：物理内存+虚拟内存。                                                                        

吞吐率：

服务器单位时间内处理的请求数，一般用来描述并发能力，当然谈吞吐率的前提是并发用户数。不同的并发用户数下，吞吐率自然大不相同。单位是“请求数/秒”。吞吐量分为网络吞吐量和事务吞吐量，当作为事务吞吐量时，采用TPS来衡量。目前线上环境Apache没有mod_status模块，不能很方便的查询。

TPS：

服务器每秒处理的事务数。PV在性能测试中的表现形式是以TPS来体现的，两者有一个转换公式，如下：

TPS平均值 =((PV*80%)/(24*60*60*40%))/服务器数量 =  pv/s

TPS峰值 =(((PV*80%)/(24*60*60*40%))*1.6) /服务器数量=  pv/s ，这个和我们经常说的“2-8原则”贴近。

一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS 。应用系统的处理能力一般要求在10-100左右。

 

 下面介绍在top命令执行过程中可以使用的一些交互命令。从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。
<空格>; 立即刷新显示。
Ctrl+L 擦除并且重写屏幕。
h或者? 显示帮助画面，给出一些简短的命令总结说明。
k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什幺样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序。
r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
S 切换到累计模式。
s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成ms。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
f或者F 从当前显示中添加或者删除项目。
o或者O 改变显示项目的顺序。
l 切换显示平均负载和启动时间信息。
m 切换显示内存信息。
t 切换显示进程和CPU状态信息。
c 切换显示命令名称和完整命令行。
M 根据驻留内存大小进行排序：查看最耗内存的进程
P 根据CPU使用百分比大小进行排序：查看最耗cpu的进程
T 根据时间/累计时间进行排序。
W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。

 

 

 

3、CPU性能评估

---

3.1、CPU介绍

       CPU 利用率很大部分取决于试图访问它的资源， 内核拥有一个管理两种资源的调度器：线程（单或多）和中断。调度器给予不同资源以不同的优先级，以下由优先级从高到低：

1） 中断——设备通知内核它们处理完成。例如网卡发送一个数据包或硬盘驱动器提供一次 IO 请求
2） 内核（系统）进程——所有的内核进程都在此级别的优先级进行处理
3）用户进程——通常被称为“用户空间” ，所有应用软件运行在用户空间，拥有最低的优先级

 

 

 

为了弄明白内核是如何管理不同的资源的，几个关键概念需要提及一下： context  switches，run queues，utilization。

Context Switches(上下文切换)：进程调度

       CPU切换到另一个进程需要保存当前进程的状态并恢复另一个进程的状态：当前运行任务转为就绪（或者挂起、中断）状态，另一个被选定的就绪任务成为当前任务。进程调度包括保存当前任务的运行环境，恢复将要运行任务的运行环境。

        大多数处理器在同一时间只能处理一个进程或线程，多线程处理器可同时处理 n 个线程。然而，linux 内核把多核处理器的各个核心当做独立核心。例如，内核把一个双核的处理当做两个独立处理器。

         一个标准的内核可同时处理 50 到 50000 个进程， 在只有一颗 CPU 的情况下， 内核必须调度和平衡这些进程和线程。 每个线程在处理器上都拥有一个时间分配单元， 当一个线程超过自己的时间单元或被更高优先级的程序抢占时， 此线程及被传回队列而此时更高优先级的程序将在处理器上执行。这种线程间的切换操作即是上下文切换。

       在linux内核中，每一个进程都存在一个名为“进程描述符”的管理表。该进程描述符会调整为按照优先级降序排序，已按合理的顺序运行进程（任务）。

进程状态：

       运行态（running） 只要cpu空闲，任何时候都可以运行
       可中断睡眠（interruptible） 为恢复时间无法预测的长时间等待状态。如，来自于键盘设备的输入。
       不可中断睡眠:（uninterruptible） 主要为短时间时的等待状态。被IO阻塞的进程，例如等待磁盘IO，网络IO，或者一个系统调用等待内核空间的返回。
       就绪态（runnable） 响应暂停信号而运行的中断状态。
       僵死态（zombie） 进程都是由父进程创建，并销毁；在父进程没有销毁其子进程，被销毁的时候，其子进程由于没有父进程被销毁，就会转变为僵死态。

运行队列：负载
      每个 CPU 维持着一个线程的运行队列， 理论上， 调度器应该是不断地运行和执行线程。线程要么处于睡眠状态，要么处于可运行状态。假如 CPU 子系统处于高负载状态，那么内核调度器罢工是有可能的， 其结果将导致可运行状态的进程开始阻塞运行队列。 运行队列越大，执行进程所花费的时间也越长。
一个很流行的术语叫“load（负载） ”经常被用来描述运行队列的状态，系统负载是由正在执行的进程和 CPU 运行队列中的进程的结合，如果有 2 个线程正在一个双核系统中执行且4 个正在运行队列中， 那么负载数即是 6， 像 top 等工具可查看过去 1,5,15 分钟的负载均值。

      load average 值包括：进程处于状态是R（运行态 running）和不可中断状态 D（D状态 uninterruptible），也就是下面这两种情况的进程才会表现为负载的值。
      1）即便需要立即使用CPU，也还需等待其他进程用完CPU
      2）即便需要继续处理，也必须等待磁盘输入输出完成才能进行
   一般来说Load简单的计算就是2* CPU个数减去1-2左右（这个只是网上看来的，未必是一个标准）。

CPU 利用率
CPU 利用率被定义为 CPU 使用的百分比， CPU 如何被利用是衡量一个系统的重要标准。多数性能监测工具把 CPU 利用分为以下几个类型：
* 用户时间——CPU 花在执行用户空间进程的时间百分比
* 系统时间——CPU 花在执行内核进程和中断的时间百分比
* IO 等待——CPU 花在等待 IO 请求完成的时间百分比
* IDLE——CPU 的空闲时间百分比

CPU的使用率= (%us + %sy + %ni)

 

理解 CPU 的性能状态即是理解中断，运行队列和上下文切换的状态。之前有提到过性能与基准信息有密切关系，但是有些常规的性能预期：
* 运行队列——每个处理器上的运行队列不应该有超过 1-3 个排队的线程。 例如， 一个双核系统不应该有超过 6 个进行在运行队列里。
* CPU 利用率——假如一个 CPU 满状态负荷，那么以下的平衡关系需要达到：
    65%–70%的用户时间
    30%–35%的系统时间
    0%–5%的空闲时间
* 上下文切换——上下文切换的数量与 CPU 的利用率有直接关系。如果 CPU 处于高负荷状态下那么大量的上下文切换是正常的。

 

3.2、利用vmstat命令监控系统CPU

   vmstat 工具的低开销使得它可以在一个高负载的系统上持续运行，它有两种工作模式：均值模式和采样模式。采样模式如下：

   该命令可以显示关于系统各种资源之间相关性能的简要信息，这里我们主要用它来看CPU一个负载情况。

   下面是vmstat命令在某个系统的输出结果：

 

[root@node1 ~]# vmstat 2 3

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    162240   8304  67032   0    0    13    21   1007   23     0  1   98   0   0

 0  0    0    162240   8304  67032   0    0     1     0     1010   20     0  1   100 0   0

 0  0    0    162240   8304  67032   0    0     1     1     1009   18     0  1    99  0   0

 

Procs

     r：运行和等待cpu时间片的进程数，这个值如果长期大于系统CPU的个数，说明CPU不足，需要增加CPU。

     b：在等待资源的进程数，比如正在等待I/O、或者内存交换等。其实就是阻塞的进程。

Memory

     swpd: 虚拟内存使用情况，单位：KB

     free: 空闲的内存，单位KB

     buff: 被用来做为缓存的内存数，一般对块设备的读写才需要缓冲，单位：KB

     cache:表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。

Swap：如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。

     si: 从磁盘交换到内存的交换页数量，单位：KB/秒。如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。

     so: 从内存交换到磁盘的交换页数量，单位：KB/秒。如果这个值大于0，同上。

I/O

     bi: 发送到块设备的块数，单位：块/秒

     bo: 从块设备接收到的块数，单位：块/秒。例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。

 

符设备和块设备的区别 ：

 

     设备文件分为Block Device Driver和Character Device Drive两类。Character Device Drive又被称为字符设备或裸设备raw devices; Block Device Driver通常成为块设备。而Block Device Driver是以固定大小长度来传送转移资料 ；Character Device Driver是以不定长度的字元传送资料 。且所连接的Devices也有所不同，Block Device大致是可以随机存取(Random Access)资料的设备，如硬碟机或光碟机；而Character Device刚好相反，依循先後顺序存取资料的设备，如印表机 、终端机等皆是。

       /dev/dsk对应的为块设备，文件系统的操作用到它，如mount。/dev/rdsk对应的为字符设备(裸设备，rdsk的r即为 raw)，fsck newfs等会涉及到。一般我们的操作系统和各种软件都是以块方式读写硬盘，这里的块是逻辑块，创建文件系统时可以选择，windows里叫簇。可看 newfs or mkfs的manual。oracle是比较常见的字符方式读写硬盘。

       字符设备还是块设备的定义属于操作系统的设备访问层，与实际物理设备的特性无必然联系。设备访问层下面是驱动程序，所以只要驱动程序提供的方式，都可以。 也就是说驱动程序支持stream方式，那么就可以用这种方式访问，驱动程序如果还支持block方式，那么你想用哪种方式访问都可以，典型的比如硬盘式 的裸设备，两种都支持块设备（block device）：是一种具有一定结构的随机存取设备，对这种设备的读写是按块进行的，他使用缓冲区来存放暂时的数据，待条件成熟后，从缓存一次性写入设备 或从设备中一次性读出放入到缓冲区，如磁盘和文件系统等字符设备（Character device）：这是一个顺序的数据流设备，对这种设备的读写是按字符进行的，而且这些字符是连续地形成一个数据流。他不具备缓冲区，所以对这种设备的读 写是实时的，如终端、磁带机等。

      系统中能够随机（不需要按顺序）访问固定大小数据片（chunks）的设备被称作块设备，这些数据片就称作块。最常见的块设备是硬盘，除此以外，还有软盘驱 动器、CD-ROM驱动器和闪存等等许多其他块设备。注意，它们都是以安装文件系统的方式使用的——这也是块设备一般的访问方式。

       另一种基本的设备类型是字符设备。字符设备按照字符流的方式被有序访问，像串口和键盘就都属于字符设备。如果一个硬件设备是以字符流的方式被访问的话，那就应该将它归于字符设备；反过来，如果一个设备是随机（无序的）访问的，那么它就属于块设备。

       这两种类型的设备的根本区别在于它们是否可以被随机访问——换句话说就是，能否在访问设备时随意地从一个位置跳转到另一个位置。举个例子，键盘这种设备提供 的就是一个数据流，当你敲入“fox”这个字符串时，键盘驱动程序会按照和输入完全相同的顺序返回这个由三个字符组成的数据流。如果让键盘驱动程序打乱顺 序来读字符串，或读取其他字符，都是没有意义的。所以键盘就是一种典型的字符设备，它提供的就是用户从键盘输入的字符流。对键盘进行读操作会得到一个字符 流，首先是“f”，然后是“o”，最后是“x”，最终是文件的结束(EOF)。当没人敲键盘时，字符流就是空的。硬盘设备的情况就不大一样了。硬盘设备的 驱动可能要求读取磁盘上任意块的内容，然后又转去读取别的块的内容，而被读取的块在磁盘上位置不一定要连续，所以说硬盘可以被随机访问，而不是以流的方式 被访问，显然它是一个块设备。

       内核管理块设备要比管理字符设备细致得多，需要考虑的问题和完成的工作相比字符设备来说要复杂许多。这是因为字符设备仅仅需要控制一个位置—当前位置—而 块设备访问的位置必须能够在介质的不同区间前后移动。所以事实上内核不必提供一个专门的子系统来管理字符设备，但是对块设备的管理却必须要有一个专门的提 供服务的子系统。不仅仅是因为块设备的复杂性远远高于字符设备，更重要的原因是块设备对执行性能的要求很高；对硬盘每多一分利用都会对整个系统的性能带来 提升，其效果要远远比键盘吞吐速度成倍的提高大得多。另外，我们将会看到，块设备的复杂性会为这种优化留下很大的施展空间。

linux驱动程序中字符设备和块设备的三点区别

1.字符设备只能以字节为最小单位访问，而块设备以块为单位访问，例如512字节，1024字节等

2.块设备可以随机访问，但是字符设备不可以

3.字符和块没有访问量大小的限制，块也可以以字节为单位来访问

 

System

 

      in: 每秒的中断数，包括时钟中断。

      cs（context switch）: 每秒的环境（上下文）切换次数。例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。

 

cpu

    us：用户进程消耗的CPU 时间百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，就需要考虑优化程序或算法。

     sy：内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源很多，即系统调用（system call）时间长，例如是IO操作频繁。

根据经验，us+sy的参考值为70%，如果us+sy大于 70%说明可能存在CPU资源不足。

  wt：等待IO CPU时间

注意：

            1）如果 r （run queue 运行队列中的进程数）经常大于 4 ，且id经常少于40，表示cpu的负荷很重。

            2）如果si，so 长期不等于0，表示内存不足。

            3）如果disk 经常不等于0， 且在 b中的队列大于3， 表示 io性能不好。

           4）其拥有很高的中断数 （in） 和很低的上下文切换数， 这说明可能有单个进程在进行大量的硬件资源请求。
            5）运行队列数刚好达到可接受的上限值，且出现超过上限值的情况。

 

什么场景会造成负载很高但CPU低？


负载总结为一句话就是：需要运行处理但又必须等待队列前的进程处理完成的进程个数。具体来说，也就是如下两种情况：

1）等待被授权予CPU运行权限的进程
2）等待磁盘I/O完成的进程
ps -eLf可以查看系统的线程。

cpu低而负载高也就是说等待磁盘I/O完成的进程过多，就会导致队列长度过大，这样就体现到负载过大了，但实际是此时cpu被分配去执行别的任务或空闲，具体场景有如下几种。

场景一：磁盘读写请求过多就会导致大量I/O等待
cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多，从而导致负载高，cpu低的情况。


场景二：MySQL中存在没有索引的语句或存在死锁等情况
我们都知道MySQL的数据是存储在硬盘中，如果需要进行sql查询，需要先把数据从磁盘加载到内存中。当在数据特别大的时候，如果执行的sql语句没有索引，就会造成扫描表的行数过大导致I/O阻塞，或者是语句中存在死锁，也会造成I/O阻塞，从而导致不可中断睡眠进程过多，导致负载过大。

具体解决方法可以在MySQL中运行show full processlist命令查看线程等待情况，把其中的语句拿出来进行优化。


场景三：外接硬盘故障，常见有挂了NFS，但是NFS server故障
比如我们的系统挂载了外接硬盘如NFS共享存储，经常会有大量的读写请求去访问NFS存储的文件，如果这个时候NFS Server故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。

场景四：访问第三方api接口
如果我们访问第三方http api，例如接口的响应时间很慢，readTimeout=2000ms，在高并发的情况下，很多线程都被中断等待api的网络IO。导致cpu使用率很低，但是load很高。
 

解决办法：
出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf  查看是否存在 D 状态进程。
D 状态是指不可中断的睡眠状态。该状态的进程无法被 kill，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。

什么场景会造成CPU跑满：

 

CPU 的跑满或跑高

1）普通进程占用很高，可以直接kill掉

2）kswapd0 进程导致的内存不足等问题，您需要对系统进行规格的升级或程序的优化。（内存优化章节有说明）

 

kswapd0 进程占用导致 CPU 较高

 

操作系统都用分页机制来管理物理内存，系统会把一部分硬盘空间虚拟成内存使用。由于内存的速度要比磁盘快得多，所以系统要按照某种换页机制将不需要的页面换到磁盘中，将需要的页面调到内存中。

kswapd0 是虚拟内存管理中负责换页的进程，当服务器内存不足的时候 kswapd0 会执行换页操作，这个换页操作是十分消耗主机 CPU 资源的。

 

 

 

3.3、mpstat命令监控系统CPU

 

如果你的系统有多个处理器核心，你就可以使用 mpstat 工具来监测每个核心。linux 内核把一个双核处理器当做 2 个 CPU，所以一个拥有 2 颗双核心的系统将被视为 4CPU。

# mpstat –P ALL 1

10:48:59 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
10:48:59 PM  all    0.32    0.00    0.22    0.07    0.01    0.01    0.00    0.00   99.37

 

3.4、利用sar命令监控系统CPU

sar功能很强大，可以对系统的每个方面进行单独的统计，但是使用sar命令会增加系统开销，不过这些开销是可以评估的，对系统的统计结果不会有很大影响。

 下面是sar命令对某个系统的CPU统计输出：

[root@webserver ~]# sar -u 3 5

Linux 2.6.9-42.ELsmp (webserver)        11/28/2008      _i686_  (8 CPU)

11:41:24 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle

11:41:27 AM     all      0.88      0.00      0.29      0.00      0.00     98.83

11:41:30 AM     all      0.13      0.00      0.17      0.21      0.00     99.50

11:41:33 AM     all      0.04      0.00      0.04      0.00      0.00     99.92

11:41:36 AM     all      90.08     0.00      0.13      0.16      0.00     9.63

11:41:39 AM     all      0.38      0.00      0.17      0.04      0.00     99.41

Average:        all      0.34      0.00      0.16      0.05      0.00     99.45

                           

如果是查看每个核心的状况，也可以使用

sar -P ALL 1 1
   
   

 

对上面每项的输出解释如下：

l        %user列显示了用户进程消耗的CPU 时间百分比。

l        %nice列显示了运行正常进程所消耗的CPU 时间百分比。

l        %system列显示了系统进程消耗的CPU时间百分比。

l        %iowait列显示了IO等待所占用的CPU时间百分比

l        %steal列显示了在内存相对紧张的环境下pagein强制对不同的页面进行的steal操作 。

l        %idle列显示了CPU处在空闲状态的时间百分比。

 具体参考：LinuxCPU利用率计算原理及内核实现(http://ilinuxkernel.com/?p=333)

问题

1.你是否遇到过系统CPU整体利用率不高，而应用缓慢的现象？

       在一个多CPU的系统中，如果程序使用了单线程，会出现这么一个现象，CPU的整体使用率不高，但是系统应用却响应缓慢，这可能是由于程序使用单线程的原因，单线程只使用一个CPU，导致这个CPU占用率为100%，无法处理其它请求，而其它的CPU却闲置，这就导致了整体CPU使用率不高，而应用缓慢现象的发生。

 

3.5、小结

CPU 的性能监测包含以下部分：
* 1）检查系统运行队列并确保每个核心上不超过 3 个可运行进程
* 2）确保 CPU 利用率的用户时间和系统时间在 70/30 之间
* 3）当 CPU 花费更多的时间在 system mode 上时，更有可能是因过载而试图重新调度优先级
* 4）运行 CPU 限制型应用比 IO 限制型应用更易出现性能瓶颈

 

 

 

 

4、内存性能评估

---

4.1、虚拟内存简介

 

       虚拟内存是使用磁盘作为 RAM 的扩充使得可用内存的有效大小得到相应增加。 内核会将当前内存中未被使用的块的内容写入硬盘以此来腾出内存空间。 当上面的内容再次需要被用到时，它们将被重新读入内存。这些对用户完全透明；在 linux 下运行的程序只会看到有大量内存空间可用而不会去管它们的一部分时不时的从硬盘读取。 当然， 硬盘的读写操作速度比内存慢上千倍， 所以这个程序的运行速度也不会很快。 这个被用作虚拟内存的硬盘空间
呗称作交换空间（swap space） 。

     （电脑中所运行的程序均需经由内存执行，若执行的程序很大或很多，则会导致内存消耗殆尽。为解决该问题，Windows中运用了虚拟内存技术，即匀出一部分硬盘空间来充当内存使用。当内存耗尽时，电脑就会自动调用硬盘来充当内存，以缓解内存的紧张。是计算机系统内存管理的一种技术。它使得应用程序认为它拥有连续的可用的内存，而实际上，它常是被分隔成多个物理内存碎片，还有部分暂存储于外部磁盘存储器上，在需要时进行数据交换。）

1）虚拟内存页

 

       虚拟内存被分成页，在 X86 架构下的每个虚拟内存页大小为 4KB，

 

       当内核由内存向磁盘读写数据时，是以页为单位。内核会把内存页写入 swap 空间和文件系统。
        盘读写数据时，是以页为单位。内核会把内存页写入 swap 空间和文件系统。

2）内核内存分页

       内存分页是一个常见的动作， 不能和内存交换相混淆。 内存分页是在正常间隔下同步内存中信息至磁盘的过程。 随着时间的增长， 应用会不断耗尽内存， 有时候内核必须扫描内存并回收被分配给其他应用的空闲页面。

3）页帧回收算法（PFRA）

PFRA 负责回收内存。PFRA 根据页类型来判断是否被回收，内存页有以下类型：
* 不可被回收——locked，kernel，reserved 被锁、内核、保留页
* 可交换——无名内存页
* 可同步——被磁盘同步的页面
* 可丢弃——静态页，废弃页
除了不可被回收类型外其他均可被 PFRA 回收。PFRA 具有两个主要功能，一个是 kswapd内核进程，一个是“Low On Memory Reclaiming”功能。

4）kswapd

kswapd 守护进程负责确保内存保持可用空闲空间。它监测内核中的 pages_high 和pages_low 标记，如果空闲内存空间值小于 pages_low 值，kswwapd 进程开始扫描并尝试每次回收 32 个页面，如此重复直至空闲内存空间大于 pages_high 值。
kswapd 进程履行以下操作：
* 假如页面未改变，它将该页面放入 free list。
* 假如页面发生改变且被文件系统回写，它将页面内容写入磁盘。
* 假如页面发生改变且未被文件系统回写（无名页） ，它将页面内容写入 swap 设备。

 

5）pdflush 内核分页

      pdflush 守护进程负责同步所有与文件系统相关的页面至磁盘，换句话说，就是当一个文件在内存中发生改变，pdflush 守护进程就将其回写进磁盘。

当内存中的脏页面数量超过 10% 时 pdflush 守护进程开始回写，这个动作与内核的vm.dirty_background_ratio 参数值有关。

sysctl -n vm.dirty_background_ratio10

 

多数情况下 pdflush 守护进程与 PFRA 之间是相互独立的。除了常规的回收动作之外，当内核调用 LMR 算法时，LMR 将强制 pdflush 进行脏页面回收。

4.2、利用free指令监控内存

free是监控linux内存使用状况最常用的指令，看下面的一个输出：

[root@webserver ~]# free  -m

                total         used       free     shared    buffers     cached

Mem:       8111       7185        926          0       243           6299

-/+ buffers/cache:     643       7468

Swap:       8189          0         8189

     一般有这样一个经验公式：应用程序可用内存/系统物理内存>70%时，表示系统内存资源非常充足，不影响系统性能，应用程序可用内存/系统物理内存<20%时，表示系统内存资源紧缺，需要增加系统内存，20%<应用程序可用内存/系统物理内存<70%时，表示系统内存资源基本能满足应用需求，暂时不影响系统性能。

          对于应用程序来说，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读取的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached.

 

     Buffers和Cached的区别：

     buffers是为块设备设计的缓冲。比如磁盘读写，把分散的写操作集中进行，减少磁盘I/O，从而提高系统性能。比如入U盘里cp一个文件，但是U盘读写指示灯未闪动，过了一会儿才闪动。卸载时会清空缓冲，所以有时卸载一个设备需要等待几秒。

    cached是缓存读取过的内容，下次再读时，如果在缓存中命中，则直接从缓存读取，否则读取磁盘。由于缓存空间有限，过一段时间以后没用的缓存会被移动到swap里面，所以有时看到物理内存还有很多，swap就被利用了。

 

 

 

4.3、利用vmstat命令监控内存

vmstat 命令除了报告 CPU 的情况外还能查看虚拟内存的使用情况，vmstat 输出的以下区域与虚拟内存有关

[root@node1 ~]# vmstat 2 3

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    162240   8304  67032   0    0    13    21   1007   23     0  1  98   0  0

 0  0    0    162240   8304  67032   0    0     1     0     1010   20     0  1  100 0  0

 0  0    0    162240   8304  67032   0    0     1     1     1009   18     0  1  99   0  0

 memory

         swpd列表示切换到内存交换区的内存数量（以k为单位）。如果swpd的值不为0，或者比较大，只要si、so的值长期为0，这种情况下一般不用担心，不会影响系统性能。

         free列表示当前空闲的物理内存数量（以k为单位）

         buff列表示buffers cache的内存数量，一般对块设备的读写才需要缓冲。

         cache列表示page cached的内存数量，一般作为文件系统cached，频繁访问的文件都会被cached，如果cache值较大，说明cached的文件数较多，如果此时IO中bi比较小，说明文件系统效率比较好。

 

swap

si列表示由磁盘调入内存，也就是内存进入内存交换区的数量。

so列表示由内存调入磁盘，也就是内存交换区进入内存的数量。

一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足。需要增加系统内存。

 

例如大规模IO写入：

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
通过以上数据可得出以下结果：
* 大量的数据从磁盘读入内存（bi） ，因 cache 值在不断增长
* 尽管数据正不断消耗内存，空闲空间仍保持在 17M 左右
* buff 值正不断减少，说明 kswapd 正不断回收内存
* swpd 值不断增大，说明 kswapd 正将脏页面内容写入交换空间（so）

4.4、TOP命令 按内存占用排序和按CPU占用排序

1：在命令行提示符执行top命令

2：输入大写P，则结果按CPU占用降序排序。输入大写M，结果按内存占用降序排序。（注：大写P可以在capslock状态输入p，或者按Shift+p）

4.5、小结：

虚拟内存的性能监测包括以下步骤：
* 当系统利用内存缓存超过磁盘缓存，系统反应速度更快
* 除在有大量持续的交换空间和磁盘读入动作情况下外， 空闲内存空间很少说明 cache得到了有效的利用
* 如果系统报告有持续的交换空间使用，说明内存不足

 

 

 

 

5、磁盘i/o性能评估

---

     熟悉RAID存储方式，可以根据应用的不同，选择不同的RAID方式。

     尽可能用内存的读写代替直接磁盘I/O，使频繁访问的文件或数据放入内存中进行操作处理，因为内存读写操作比直接磁盘读写的效率要高千倍。

     将经常进行读写的文件与长期不变的文件独立出来，分别放置到不同的磁盘设备上。

     对于写操作频繁的数据，可以考虑使用裸设备代替文件系统。

        

       使用裸设备的优点有：

       数据可以直接读写，不需要经过操作系统级的缓存，节省了内存资源，避免了内存资源争用。

       避免了文件系统级的维护开销，比如文件系统需要维护超级块、I-node等。

       避免了操作系统的cache预读功能，减少了I/O请求。

       使用裸设备的缺点是：

           数据管理、空间管理不灵活，需要很专业的人来操作。

 

5.1、磁盘存储基础

        磁盘 IO 子系统是 linux 系统里最慢的部分，这是由于其与 CPU 相比相去甚远，且依赖于物理式工作（转动和检索） 。如果将读取磁盘和读取内存所花费的时间转换为分秒，那么他们之间的差距是 7 天和 7 分钟，所以 linux 内核尽量少的进行磁盘操作是至关重要的。以下部分将描述下内核处理数据从磁盘到内存和从内存到磁盘的不同方式。

 

1）数据读写——内存页面
linux 内核将磁盘 IO 分为页面进行操作， 大多数 linux 系统中默认页面大小为 4K， 即以4K 为单位进行磁盘和内存间的读写操作。我们可以使用 time 命令来查找页面大小：

# /usr/bin/time -v date
……
Page size (bytes): 4096

2）主要页错误（Major Page Faults）和次要页错误（Minor PageFaults）
        linux 和大多数 UNIX 系统一样，使用虚拟内存层来映射物理地址空间，这种映射在某种意义上是说当一个进程开始运行，内核仅仅映射其需要的那部分，内核首先会搜索 CPU缓存和物理内存，如果没有找到内核则开始一次 MPF， 一次 MPF 即是一次对磁盘子系统的请求，它将数据页从磁盘和缓存读入 RAM。一旦内存页被映射到高速缓冲区，内核便会试图使用这些页，被称作 MnPF,MnPF 通过重复使用内存页而缩短了内核时间。
 

在下面示例中，time 命令显示了当一个程序启动的时候产生了多少 MPF 和 MnPF，在第一次启动的时候产生了很多 MPF：

# /usr/bin/time -v evolution
……
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
……
第二次启动的时候 MPF 消失因为程序已经在内存中：
# /usr/bin/time -v evolution
……
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
……

3）文件缓冲区
文件缓冲区可使内核减少对 MPFs 和 MnPFs 的使用， 随着系统不断地 IO 操作， 缓冲区会随之增大， 直至内存空闲空间不足并开始回收， 最终结果是系统管理员们开始关心这个事实，但这只是系统正在很好的使用缓冲空间而已。

下面的输入来自/proc/meminfo 文件：

# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
……
以上显示系统拥有 2G 内存， 当前有 52MB 空闲空间， 24MB 的 buffer 供应磁盘写操作， 1.7GB的 cache 由磁盘读入内存。内核通过 MnPF 机制来使用这些东东，光这些数据还不足以说明系统出现瓶颈。

4）内存页面分类
在 linux 内核中有 3 种内核页：
* 读取页面——从磁盘读入（MPF）的只读页面，这些页面存在于缓冲区中包括不可改变的静态文件，二进制文件和库文件。内核会因需求而不断地将他们读入内存，如
果内存变得不够用，内核会将他们“窃取”至空闲列表，这将导致某个应用通过 MPF将它们重新加载至内存。
 

        * 脏页面——在内存中被内核修改的页面，它们将被 pdflush 守护进程回写至磁盘， 当内存不够用时，kswapd 进程也会和 pdflush 一道进行回写以释放更多内存空间。
 

* 无名页面——它们属于某个进程，但是没有任何文件或后端存储与之关联，它们不能被回写进磁盘，当内存不够用时 kswapd 守护进程会将它们写入交换空间直至 RAM
释放出来。

 

5）数据页面磁盘回写
应用可能直接调用 fsync()或 sync()系统调用将脏页面回写入磁盘， 这些系统调用会直接请求至 I/O 调度器。如果一个应用不调用它们，则 pdflush 守护进程会时不时地进行页面回写操作。

 

 

5.2、监测磁盘 I/O

在一定条件下系统会出现 I/O 瓶颈，可由很多监测工具监测到，如 top，vmstat，iostat，sar 等。这些工具输入的信息大致一样，也有不同之处，下面将讨论出现 I/O 瓶颈的情况。

 

计算每秒 IO 量：
每一次向磁盘的 IO 请求都会花费一定时间，这主要是因为磁盘必须旋转，磁头必须检索。磁盘的旋转通常被称为“旋转延迟(rotational delay)” （RD） ，磁头的移动杯称为“磁盘
检索(disk seek)” （DS） 。因此每次 IO 请求的时间由 DS 和 RD 计算得来，磁盘的 RD 由驱动气的转速所固定，一 RD 被为磁盘一转的一半，计算一块 10000 转磁盘的 RD 如下：
1. 算出每转的秒数：60 秒/10000 转 = 0.006 秒/转
2. 转换为毫秒： 0.006*1000 毫秒 = 6 毫秒
3. 算出 RD 值： 6/2 = 3 毫秒
4. 加上平均检索时间：3+3 = 6 毫秒
5. 加上内部转移等待时间： 6+2 = 8 毫秒
6. 算出一秒的 IO 数：1000 毫秒/8 毫秒 = 125 次/秒（IOPS）
在一块万转硬盘上应用每请求一次 IO 需要 8 毫秒，每秒可提供 120 到 150 次操作。

 

（2）利用iostat评估磁盘性能

[root@webserver ~]#   iostat -d 2 3

Linux 2.6.9-42.ELsmp (webserver)        12/01/2008      _i686_  (8 CPU)

 

Device:         tps  Blk_read/s   Blk_wrtn/s  Blk_read      Blk_wrtn

sda               1.87         2.58       114.12        6479462     286537372

 

Device:         tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn

sda               0.00         0.00         0.00              0                0

 

Device:         tps   Blk_read/s   Blk_wrtn/s   Blk_read    Blk_wrtn

sda               1.00         0.00        12.00             0                24

对上面每项的输出解释如下：

tps平均每秒钟的IO请求次数

Blk_read/s表示每秒读取的数据块数。

Blk_wrtn/s表示每秒写入的数据块数。

Blk_read表示读取的所有块数。

Blk_wrtn表示写入的所有块数。

Ø            可以通过Blk_read/s和Blk_wrtn/s的值对磁盘的读写性能有一个基本的了解，如果Blk_wrtn/s值很大，表示磁盘的写操作很频繁，可以考虑优化磁盘或者优化程序，如果Blk_read/s值很大，表示磁盘直接读取操作很多，可以将读取的数据放入内存中进行操作。

Ø            对于这两个选项的值没有一个固定的大小，根据系统应用的不同，会有不同的值，但是有一个规则还是可以遵循的：长期的、超大的数据读写，肯定是不正常的，这种情况一定会影响系统性能。

 

（3）利用sar评估磁盘性能

         通过“sar –d”组合，可以对系统的磁盘IO做一个基本的统计，请看下面的一个输出：

[root@webserver ~]# sar -d 2 3

Linux 2.6.9-42.ELsmp (webserver)        11/30/2008      _i686_  (8 CPU)

 

11:09:33 PM  DEV     tps   rd_sec/s   wr_sec/s  avgrq-sz  avgqu-sz  await  svctm   %util

11:09:35 PM dev8-0  0.00  0.00            0.00        0.00          0.00         0.00   0.00     0.00

 

11:09:35 PM  DEV     tps  rd_sec/s    wr_sec/s  avgrq-sz  avgqu-sz await   svctm   %util

11:09:37 PM dev8-0  1.00  0.00         12.00        12.00         0.00        0.00    0.00     0.00

 

11:09:37 PM   DEV    tps    rd_sec/s  wr_sec/s   avgrq-sz  avgqu-sz await  svctm   %util

11:09:39 PM dev8-0  1.99   0.00         47.76         24.00       0.00        0.50    0.25     0.05

 

Average:  DEV          tps    rd_sec/s   wr_sec/s  avgrq-sz  avgqu-sz   await  svctm   %util

Average:  dev8-0      1.00   0.00          19.97         20.00       0.00         0.33    0.17     0.02

      需要关注的几个参数含义：

     await表示平均每次设备I/O操作的等待时间（以毫秒为单位）。

     svctm表示平均每次设备I/O操作的服务时间（以毫秒为单位）。

     %util表示一秒中有百分之几的时间用于I/O操作。

 

对以磁盘IO性能，一般有如下评判标准：

     正常情况下svctm应该是小于await值的，而svctm的大小和磁盘性能有关，CPU、内存的负荷也会对svctm值造成影响，过多的请求也会间接的导致svctm值的增加。

     await值的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式，如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢，此时可以通过更换更快的硬盘来解决问题。

     %util项的值也是衡量磁盘I/O的一个重要指标，如果%util接近100%，表示磁盘产生的I/O请求太多，I/O系统已经满负荷的在工作，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，可以通过优化程序或者通过更换更高、更快的磁盘来解决此问题。

 

（4）利用iotop评估磁盘性能

 

 

Linux下的IO统计工具如iostat, nmon等大多数是只能统计到per设备的读写情况, 如果你想知道每个进程是如何使用IO的就比较麻烦.

iotop 是一个用来监视磁盘 I/O 使用状况的 top 类工具。iotop 具有与 top 相似的 UI，其中包括 PID、用户、I/O、进程等相关信息。

简单安装：yum -y install iotop

iotop [OPTIONS]：

–version #显示版本号
-h, –help #显示帮助信息
-o, –only #显示进程或者线程实际上正在做的I/O，而不是全部的，可以随时切换按o
-b, –batch #运行在非交互式的模式
-n NUM, –iter=NUM #在非交互式模式下，设置显示的次数，
-d SEC, –delay=SEC #设置显示的间隔秒数，支持非整数值
-p PID, –pid=PID #只显示指定PID的信息
-u USER, –user=USER #显示指定的用户的进程的信息
-P, –processes #只显示进程，一般为显示所有的线程
-a, –accumulated #显示从iotop启动后每个线程完成了的IO总数
-k, –kilobytes #以千字节显示
-t, –time #在每一行前添加一个当前的时间
-q, –quiet #suppress some lines of header (implies –batch). This option can be specified up to three times to remove header lines.
-q column names are only printed on the first iteration,
-qq column names are never printed,
-qqq the I/O summary is never printed.

 

 

 

 

 

 

 

6、网络性能评估

---

 网络是所有子系统中最难监测的一个， 因为网络比较抽象， 在监测时有很多在系统可控制之外的因素如延迟，冲突，拥塞和丢包等对监测产生影响。下面将讨论的是以太网、IP、TCP 的性能监测。

1）以太网配置设定

除非有明确的设定， 所有以太网的速度都是自动协商的， 这很大程度上是由于历史原因造成的，早些时候一个网络里经常有不同网速和双工模式的网络设备。
大多数企业以太网是 100BaseTX 或 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: 0x00000007 (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

2）网络吞吐量监测
监测网络吞吐量最好的办法是在两个系统之间发送流量并统计其延迟和速度。

3）使用 iptraf 监测本地吞吐量

简单安装：yum install -y iptraf  

在centos7.2使用的命令是：

[root@huangguisu]# find /usr/ -name iptra*
/usr/sbin/iptraf-ng

使用iptraf-ng -d eth0

iptraf 工具可提供以太网卡的吞吐量情况：

# iptraf -d eth0

上面的数据显示被测试系统正以 61mbps（7.65M）频率发送数据，相比于 100mbps 网络这有点低。

 

使用iptraf 命令找出流量使用情况和接口、端口信息

输入命令： iptraf  

 

然后iptraf 会给出如下所示的输出。结果给出了两样东西，源地址和网络端口号。在第一次出现的welcome屏幕上按下Enter，就可以看见具体的选项了。一旦你选择了在所有接口之上的“IP traffic monitor”选项：

你会看到如下的输出结果。

 

 

4）使用 netperf 监测远端吞吐量
与 iptraf 的动态监测不一样的是 netperf 使用可控方式测试网络， 这一点对测试一个客户端到一个高负载服务器之间的吞吐量很有帮助，netperf 工具是以 C/S 模式运行。
首先需要在服务器上运行 netperf 服务端：

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

netperf 可以执行多种测试，最基本的是标准测试：

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 SizeTimeThroughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638430.0289.46

 

输出显示吞吐量在 89mbps 左右，服务器和客户端在同一网段。从一个 10 跳的 54G 无线网进行测试只能达到 14mbps 左右：
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 跳距离局域网测试：

# 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 SizeTimeThroughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638430.645.05

从外网测试：

netperf -H litemail.org -p 1500 -l 30

litemail.org (72.249.104.148) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size SizeTimeThroughput
bytes bytes bytessecs.10^6bits/sec
87380 16384 1638431.580.93

 

另外一个有用的测试模式是测试 TCP 请求应答速率， 其原理是建立一个 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. ElapsedTrans.
Send Recv SizeSizeTimeRate
bytes Bytes bytesbytessecs.per sec
16384 87380 1130.00 4453.80
16384 87380

数据显示网络可支持 4453 左右的 psh/ack 每秒，因为发送包的大小只有 1k。下面使用 2k的请求和 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 RequestResp.ElapsedTrans.
Send Recv SizeSizeTimeRate
bytes Bytes bytesbytessecs.per sec
16384 87380 20483276830.00222.37
16384 87380

可以看到速率已经降到 222 左右。

/

 

（1）通过ping命令检测网络的连通性

（2）通过netstat –i组合检测网络接口状况

（3）通过netstat –r组合检测系统的路由表信息

（4）通过sar –n组合显示系统的网络运行状态 

 

l  netstat -antl  查看所有tcp status：

注意：可以通过netstat查看是否timewait过多的情况，导致端口不够用，在短连接服务中且大并发情况下，要不系统的net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle两个选项打开，允许端口重用。具体这两个属性如何用，移步线上/etc/sysctl.conf文件配置，有注释。

 

sar查看网卡性能：sar -n DEV 1 100

Linux 2.6.32-431.20.3.el6.x86_64 (iZ25ug3hg9iZ)         09/18/2014      _x86_64_        (4 CPU)

04:01:23 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
04:01:24 PM        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
04:01:24 PM      eth0      4.04      0.00      0.16      0.00      0.00      0.00      0.00
04:01:24 PM      eth1     26.26      0.00      1.17      0.00      0.00      0.00      0.00

 

 

各列含义：

IFACELAN接口

rxpck/s每秒钟接收的数据包

txpck/s每秒钟发送的数据包

rxbyt/s每秒钟接收的字节数

txbyt/s每秒钟发送的字节数

rxcmp/s每秒钟接收的压缩数据包

txcmp/s每秒钟发送的压缩数据包

rxmcst/s每秒钟接收的多播数据包

其实中间的IFACELAN bond0是虚拟设备。在RH中，多个物理网卡帮定为一个逻辑bonding设备，通过把多个物理网卡帮定为一个逻辑设备，可以实现增加带宽吞吐量，提供冗余。如何进行虚拟化和模式选择，请参考下面两篇文章。

 

 

 

 

7、监控利器

---

 dstat是一个用来替换vmstat,iostat netstat,nfsstat和ifstat这些命令的工具, 是一个全能系统信息统计工具.它是由Python编写的， 与sysstat相比,dstat是以一个彩色的界面动态显示,这样数据比较显眼,容易观察，一目了然; 而且dstat支持即时刷新,可以使用相关参数指定显示哪些内容！下后会有说明。下面开始进入dstat的神秘世界!!!!!!!!!!!!!!官方站点：http://dag.wieers.com/home-made/dstat/#download

 

 

 

nginx+php-fpm的并发处理能力计算：

php-fpm进程执行时间=t ms

服务器cpu函数=n

并发执行能力qps= 1s/t * 1000 *n.

如果平均php-fpm进程执行时间10ms， cpu=4核。 并发处理能力=1/10 × 1000 ×4= 400.

 

QPS = req/sec = 请求数/秒

【QPS计算PV和机器的方式】

QPS统计方式 [一般使用 http_load 进行统计]
QPS = 总请求数 / ( 进程总数 *   请求时间 )
QPS: 单个进程每秒请求服务器的成功次数

单台服务器每天PV计算
公式1：每天总PV = QPS * 3600 * 6
公式2：每天总PV = QPS * 3600 * 8

服务器计算
服务器数量 =   ceil( 每天总PV / 单台服务器每天总PV )

【峰值QPS和机器计算公式】

原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS   = 需要的机器

问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

问：如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3

 

 

注意：如果 r经常大于 4 ，且id经常少于40，表示cpu的负荷很重。

          如果si，so 长期不等于0，表示内存不足。

          如果disk 经常不等于0， 且在 b中的队列大于3， 表示 io性能不好。