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