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

网络内容总结（感谢原创）

一、前言简介

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 服务，以及任何类型的渲染服务都被归到此类。

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。

3、系统性能分析工具

1.经常使用系统命令 

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

 

2.经常使用组合方式 

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

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

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

•           用netstat检测是不是网络带宽瓶颈

 

Linux性能评估与优化：

      cpu，内存，IO, 网络

二、负载：总体性能评估

系统总体性能评估（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 命令的执行结果。其内容以下：当前时间；系统运行时间，格式为时:分；当前登陆用户数；系统负载，即任务队列的平均长度。

第2、三行为进程和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左右。

 

三、CPU性能评估

1、CPU介绍

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

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

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

Context Switches(上下文切换)：

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

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

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

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

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

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

     si: 从磁盘交换到内存的交换页数量，单位：KB/秒

     so: 从内存交换到磁盘的交换页数量，单位：KB/秒

I/O

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

     bo: 从块设备接收到的块数，单位：块/秒

System

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

      cs: 每秒的环境（上下文）切换次数

cpu

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

     sy：内核进程消耗的CPU时间百分比。Sy的值较高时，说明内核消耗的CPU资源不少。

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

注意：

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

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

            3）若是disk 常常不等于0， 且在 b中的队列大于3， 表示 io性能很差。

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

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

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

                           

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

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使用率不高，而应用缓慢现象的发生。

 

5、小结

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

四、内存性能评估

1、虚拟内存简介

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

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 进行脏页面回收。

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%时，表示系统内存资源基本能知足应用需求，暂时不影响系统性能。

  

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、小结：

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

五、磁盘i/o性能评估

l             熟悉RAID存储方式，能够根据应用的不一样，选择不一样的RAID方式。

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

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

l              对于写操做频繁的数据，能够考虑使用裸设备代替文件系统。

        

       使用裸设备的优势有：

ü           数据能够直接读写，不须要通过操做系统级的缓存，节省了内存资源，避免了内存资源争用。

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

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

       使用裸设备的缺点是：

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

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 守护进程会时不时地进行页面回写操做。

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系统已经满负荷的在工做，该磁盘可能存在瓶颈。长期下去，势必影响系统的性能，能够经过优化程序或者经过更换更高、更快的磁盘来解决此问题。

 

六、网络性能评估

 网络是全部子系统中最难监测的一个， 由于网络比较抽象， 在监测时有不少在系统可控制以外的因素如延迟，冲突，拥塞和丢包等对监测产生影响。下面将讨论的是以太网、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 监测本地吞吐量
iptraf 工具可提供以太网卡的吞吐量状况：
# iptraf -d eth0

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

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 Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.02 89.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设备，经过把多个物理网卡帮定为一个逻辑设备，能够实现增长带宽吞吐量，提供冗余。如何进行虚拟化和模式选择，请参考下面两篇文章。

七、监控利器

 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性能很差。