效能調優概述,這是一篇最通俗易懂的效能調優總結

luashin發表於2016-03-25
   效能調優就是對計算機硬體、作業系統和應用有相當深入的瞭解,調節三者之間的關係,實現整個系統(包括硬體、作業系統、應用)的效能最大化,並能不斷的滿足現有的業務需求。本文將詳細為您進行解析
  1. 概述
  2. 什麼是效能調優?(what)
  3. 為什麼需要效能調優?(why)
  4. 什麼時候需要效能調優?(when)
  5. 什麼地方需要效能調優?(where)
  6. 什麼人來進行效能調優?(who)
  7. 怎樣進行效能調優?(How)
  8. 總結

硬體配置:CUP Xeon E5620 x 2 8核心, 記憶體 16G , 硬碟 RAID 10,作業系統: CentOS 6.4 x86_64(64位)

一、概述

   在這篇博文中,不用一些抽象的概念去說效能調優的問題,只用最通俗的語言儘量來準確的表達我的想法。由於水平有限,有什麼不對或者不清楚的地方歡迎大家交流指正。為了更能通俗易懂的理解我們即將要的效能調優的話題,這裡簡單的和大家說一下寫這篇文章的寫作方法5w+1h方法。

,5w+1h就是對所做工作進行科學的分析,對某一工作在調查研究的基礎上:

  • 就其工作內容(What)
  • 責任者(Who)
  • 工作崗位(Where)
  • 工作時間(When)
  • 怎樣操作(How)
  • 以及為何這樣做(Why)

即”5W”、”1H”進行書面描述,並按此描述進行操作,達到完成職務任務的目標。(來源“百度百科”)

聽過馬哥課程的一定不陌生!

二、什麼是效能調優?(what)

 

   在說什麼是效能調優之前,先來說一下,計算機的體系結構。如上圖,簡單來說包括三塊:硬體、作業系統、應用程式。其實,效能調優就是調節這些內容,包括硬體、作業系統、應用程式。其中,這三大方面中又包含了若干的內容。

硬體包括:CPU、記憶體、磁碟、網路卡、其它……,

作業系統包括:程式、虛擬記憶體、檔案系統、網路、其它……,

應用程式就不用多說了大家都懂,常見的有:Apache、MySQL、Nginx、Memcahed等。

那什麼是效能調優呢?

效能調優就是對計算機硬體、作業系統和應用有相當深入的瞭解,調節三者之間的關係,實現整個系統(包括硬體、作業系統、應用)的效能最大化,並能不斷的滿足現有的業務需求。這就是我們所說的效能調優。

三、為什麼需要效能調優?(why)

   下面來說一說為什麼需要進行效能調優,其實說到底就兩原因:一是為了獲得更好的系統效能(就是現有的系統執行的還不錯,但最佳化一下可以執行的更好)。二是透過效能調優來滿足不斷增加的業務需求。為了更直觀的幫助大家來理解為什麼要進行效能調優?分別從三個方面來說:

  • 硬體選型(根據伺服器應用型別來選購伺服器)
  • 作業系統發行版本 (選擇發行版本)
  • 應用程式 (Apache、Nginx、MySQL等)


1.硬體選型

  不管是租伺服器也好還是自己買伺服器也好都會遇到一個問題,選擇什麼樣硬體配置的伺服器,一般是根據應用型別來選擇伺服器。因為不可能一種硬體配置來滿足所有的應用需求,而每個應用的具體需求不一樣。下面來看一下在專案實施中有哪些應用型別:

  • 負載均衡:效能要求相對較低,因為只負責轉發資料,但要保證選一效能突出的網路卡即可。(推薦配置:CPU E5620 x 1、記憶體 8G、硬碟 500G(RAID5))
  • Web 伺服器:一般只處理一些靜態頁面或者圖片等,因此要求也不是很高,主流的伺服器都可以。(推薦配置:CPU E5620 x 1、記憶體 16G、硬碟 500G(RAID5))
  • 應用伺服器:一般應用程式服器,它承擔網站功能的實現,在架構中佔有比較重的位置,特別是網站架構中只有一臺應用伺服器時,對CPU、記憶體、磁碟要求都比較高。(推薦配置:CPU E5620 x 2、記憶體 32G、硬碟 500G(RAID10))
  • 快取伺服器:分為前端頁面快取與後面資料快取,它們典型的應用分別是Varnish、SQ與Memcached,對記憶體的要求比較大,一般我們配置伺服器時使用較大有記憶體。(推薦配置:CPU E5620 x 1 記憶體 32G 硬碟 500G(RAID10))
  • 資料庫伺服器:資料伺服器對CPU、記憶體、磁碟的要求都很高,一但某個硬體是短板都會帶來效能問題。(推薦配置:CPU E5620 x 2 記憶體 64G 固態硬碟 500G(RAID10))
  • 備份伺服器:備份伺服器一般就沒有什麼要求,但有點可以肯定是必須有足夠大的硬碟空間。(推薦配置:CPU E5620 x 1 記憶體 4G 硬碟 2TB(RAID5))
  • 監控伺服器:一般也沒什麼需要,普通的PC伺服器就可以。(推薦配置:CPU E5620 x 1 記憶體 4G 硬碟 500(RAID5))
  • 其它伺服器:至於其它伺服器就看各位的具體需要具體分析了。

   這下各位知道什麼是硬體的效能調優了吧,根據你具體的應用,進行具體分析特別是像MySQL這樣的伺服器,對CPU、記憶體、磁碟要求都比較高。所以,對硬體的效能調優必須做到選擇合適的硬體配置。這是網站架架構或者專案實施首先要解決的問題!

2.作業系統

   有本書叫《Linux Performance Tuning》(Linux 效能調優)這本書是老外寫的,作者是 Fernando Apesteguia 。
  為什麼需要效能調優?他得出的結論是這樣的:

“當一個發行版打包傳送到客戶手中的時,它是為了完全相容市場中大部分計算機而設計的。這是一個相當混雜的硬體集合(硬碟,顯示卡,網路卡,等等)。所以Red Hat,SUSE,Mandriva,Ubuntu和其他的一些發行版廠商選擇了一些保守的設定來確保安裝成功。”簡單的說,你的作業系統已經執行的不錯了,但是你可以調節它獲得更高的效能,比如你有個高效能的磁碟,但你的作業系統中一些選項引數預設沒有啟動,就不能實現這些高階功能來提高硬碟效能。

   還有我想說就是對作業系統發行版選擇的問題,RedHat或CentOS這些作業系統在專案實施或網站架構中用的比較多,主要針對企業應用而開發的作業系統。而Ubuntu之類的作業系統對桌面支援的比較好,所以選擇發行版本時得注意。(一般企業中用的比較多的是CentOS),再有就是我們一般不要選擇最新的發行版,因為剛出來的發行版相對來說bug還比較多,不要先當“小白鼠”,比如:剛剛出來CentOS 7等過一段時間穩定了再使用,目前我們可以選擇CentOS 6.4 或 6.5即可。(但新版本也有很多好處,新版本中加入了很多新功能,去掉習已知bug,對於一些不重要的應用,可嘗試使用新的作業系統)

3.應用程式

   最後,來說說應用程式了,先來簡單看到一下Apache的MPM配置檔案:

prefork 模型:
StartServers 8 
MinSpareServers 5 
MaxSpareServers 20 
ServerLimit 256 
MaxClients 256 
MaxRequestsPerChild 4000 

   從上面的配置檔案中可以看出,apache 開始啟動時啟用 8個程式,最小 5個程式,最大20個程式,每個程式限制請求數為256個,最多可以接受請求 4000個,超過這個限制數自動銷燬。

worker 模型:
 StartServers 2 
MaxClients 150 
MinSpareThreads 25 
MaxSpareThreads 75 
ThreadsPerChild 25 
MaxRequestsPerChild 0 

   再看一下,worker模型的配置檔案,預設啟動2個程式,每個程式可以接受的請求為150個,每個程式中最小執行緒數25個,最大執行緒數為75個,預設執行緒數25個,每個執行緒可以接受的請求沒有限制為0。

   好了!大家看完上面的配置檔案,可以看出預設的Apache配置檔案,設定的比較保守,只適於一些中小網站,想要獲得高效能的Apache伺服器還必須進行效能調優,包括apache編譯選項,配置檔案最佳化等,具體的調優我們在這裡先不細說。

   透過我們上面的講解,分別從硬體、作業系統、應用程式,這三個方面入手和大家談談為何需要效能調優,相信大家已經知道並瞭解,相信大家都迫不及待了吧。

   嘿嘿!先不急還有很多問題沒有說清楚,下面我們和大家來說說,什麼時候需要效能調優?

四、什麼時候需要效能調優?(when)

一般分為兩個時間段:

  • 上線前(基本最佳化)
  • 上線後(持續最佳化)

   為什麼這樣說呢?一般在專案實施到專案上線這段時間,不單要準備硬體伺服器、安裝作業系統、環境搭建,還有個很重要的問題就是要進行效能最佳化,包括作業系統最佳化和應用環境最佳化等,我們稱上線前的最佳化為“基本最佳化”,也可稱為“經驗最佳化”。
  根據做過的專案和工作中的經驗對上線前的伺服器或架構進行基本的效能最佳化來滿足業務需求。再有就是專案上線後的最佳化,在上線前已經經過基本的效能最佳化,解決了大部分的效能問題,但畢竟上線前的所以測試都是模擬測試並進行相關的效能最佳化,與上線後的真實環境還是有相當大的區別。
   首先要做的就是對上線後的專案進行效能監控,包括:伺服器效能監控和服務效能監控。

伺服器效能監控包括:CPU使用率、CPU負載、記憶體使用率、磁碟I/O、磁碟空間使用率、網路流量、系統程式等。服務效能監控包括:Apache、Nginx、MySQL。

   以上架構中所有的服務都需要進行效能監控,一旦發現有問題我們都得去進行效能最佳化,在這個過程中我們稱為“持續最佳化”,也稱為“監控最佳化”。下面我們來具體的說一下,具體什麼地方需要進行效能調優?

五、什麼地方需要效能調優?(where)

   在上面我們說效能調優只說一些大的方面,包括硬體、作業系統、應用程式這三大塊。其實還有一塊就是程式本身的最佳化,開發人員根據需求開發出來的程式本身就需要效能最佳化,但對於我們運維人員來說接觸的比較少而已。下面我們就來看看這三大塊:

  • 硬體 (CPU、記憶體、磁碟、網路卡)
  • 作業系統(程式、檔案系統、核心 ……)
  • 應用程式(Apache、Nginx、MySQL ……) 
  •  

1.硬體

硬體最佳化一般也包括兩塊:

  • 上線前(硬體選型)
  • 上線後(硬體擴充套件)

   一般專案搭建時都需要根據具體的應用進行硬體配置選型,在這方面需要一定的運維經驗,剛接觸的朋友在這方面可能有點欠缺,但沒事一般做過一兩個專案以後,對硬體配置選型也就會了。但有個不成文的經驗,硬體的配置還是越高越好。

   我們為什麼說需要根據具體的應用來選型呢,一方面是什麼樣的應用需要什麼樣的硬體配置,還有點很重要就是節約成本,錢得要在刀刃上不該花的錢我們不能亂花,也是為公司節約成本,實現資源利用最大化。

   上面我們說的是專案搭建初期,你運氣比較好專案一開始你就在這邊。一般有經驗的運維工程師在硬體選型是不會有問題的,所以在效能最佳化時就不考慮硬體這塊,從理論上講伺服器硬體配置一般不會出現在這種效能問題上。但是,由於我們業務做的越來越好,專案建立初期沒有考慮到會有這麼大的效能需要(訪問量),現在有的硬體不能滿足業務需求,所以這時需要更換更好的CPU、更大的記憶體和更快的磁碟。至於如何找出硬體是效能瓶頸在這裡不細說,在後面的文章中將會細說。最後來看一張硬體架構圖,能幫助你更好的理解硬體最佳化,如下圖(Dell R 710 架構):

 

2.作業系統

   下面來說作業系統,其實絕大部分的最佳化都在在作業系統和應用程式上的最佳化,除了上線前的硬體選型和上線後的硬體擴充套件,下面就來看看作業系統最佳化包括哪些:

  • 作業系統安裝最佳化
  • 系統初始化
  • 程式調優
  • 記憶體調優
  • IO 調優
  • 檔案系統調優
  • 網路調化

下面來看一張圖,可以更直觀的幫且我們理解,如下圖:

 

3.應用程式

   最後來說說應用程式最佳化,這裡以MySQL最佳化為例,讓大家更直觀的瞭解。

  • MySQL 編譯安裝最佳化
  • MySQL 配置檔案最佳化
  • 索引最佳化
  • MySQL 引擎最佳化
  • 查詢快取最佳化
  • SQL 語句最佳化
  • 最佳化表型別(MyISAM或InnoDB)
  • 鎖機制最佳化
  • MySQL 伺服器最佳化(換SSD)

   透過上面的對硬體、作業系統、應用程式的具體說明相信,大家對效能最佳化有了更深層次的瞭解,下面我們來說一個重要的問題,什麼人來進行效能最佳化?

六、什麼人來進行效能調優?(who)

   一說起效能最佳化我們第一個想到的是運維工程師,他們來進行最佳化。其實我想說,這麼說是片面的效能最佳化不僅僅是運維工程師的事。

   其實呢!效能最佳化是一個團隊的事。為什麼這麼說呢?下面我們就來說一下:大家想啊!一公司需要做一專案,我們就拿最常見的電子商務中商城的專案來說吧,公司確認由於業務需要我們需要在網上做一個建材商城,那專案的具體流程是什麼呢?可能不是很詳細,但大體過程是樣的:

  • 運營提出需求
  • 產品整理需求
  • 開發開發具體的業務應用
  • 運維搭建開發環境
  • QA 進行專案測試
  • 運維進行專案上線
  • 監控進行專案監控

   開發一個具體的應用需要運營部、產品部、開發部、運維部、QA (測試)、監控等所有部門的參加。同樣的一個專案(業務)存在效能問題,不會只是運維部門需要進行效能調優,而是所有部門一起來解決這個效能問題,這是缺一不可的。可能出現在產品上,也可能出現在程式上(*.php),還可能是業務需要本身就有問題,更有可能是運維的環境搭建有問題。但參加效能調優的更多的是開發、運維、測試和監控。


七、怎麼樣進行效能調優?(How)

   下面進入正題說一說怎麼進行效能調優?具體步驟如下:

  • 效能指標 –> 確認衡量標準
  • 效能測試 –> 驗證效能指標
  • 效能分析 –> 找出效能瓶頸
  • 效能調優 –> 解決效能問題
  • 效能監控 –> 檢驗調優效果


1.效能指標

   上面我們說了,最佳化的目的是為了獲得更好的效能,那麼效能指標是什麼呢?怎麼樣來衡量!一般衡量一個專案(這裡指的網站)的指標有三個:

  • 吞吐量 –> 是單位時間內完成的使用者或系統的請求數量。
  • 併發數 –> 同時能接受多少使用者的訪問請求
  • 響應時間 –> 從使用者發出請求到收到響應的時間間隔。


2.效能測試

   做產品或者說專案(更直白的說是網站)的目的是為了讓使用者使用。我們得先站在使用者的角度分析一下,使用者需要關注哪些效能?對於使用者來說,當點選一個按鈕、連結或發出一個操作指令,到系統把請求處理好發給使用者並用網頁的形式展現出來為止,這個過程中所消耗的時間是使用者對這個網站效能的直觀印象。也就是我們所說的響應時間,當響應時間較小時,使用者體驗相對來說就會好,當然使用者體驗的響應時間包括個人主觀因素和客觀響應時間。在網站開發與搭建時,我們就需要考慮到如何更好地結合這兩部分達到使用者最佳的體驗。使用者關注的是使用者操作的相應時間。其次,站在運維的角度考慮需要關注的效能點。再次,我們得站在開發(設計)人員角度去考慮網站效能。最後,由QA測試與反饋我們網站效能。
  經過上述的說明,我們來測試系統的效能,需要收集系統的吞吐量、併發數、響應時間這三個重要的指標。具體步驟是:

  • 確認吞吐量、併發數、響應時間這三個值
  • 找到或開發相應的效能測試工具
  • 進行效能測試
  • 反饋結果並提交測試報告

   結果有兩種,一種是:達到我們預期的效能目標,這樣我們就不需要效能最佳化任務完成可以交給運維上線,只需要進行相關的效能監控,方便上線後進行效能最佳化。另一種是:沒有達到預期的目標,要查詢效能瓶頸並進行效能最佳化。

3.效能分析

   透過上面的效能測試,發現網站沒有達到我們預期定義的效能目標,這時需要做的就是對現有的系統(伺服器)進行監控,包括硬體與軟體監控,為效能調優提供有效的效能監控資料。

   下面重點來說一下,用什麼工具能找出效能瓶頸:

硬體:

  • 用vmstat、sar、iostat檢測是否是CPU瓶頸
  • 用free、vmstat檢測是否是記憶體瓶頸
  • 用iostat檢測是否是磁碟I/O瓶頸
  • 用netstat檢測是否是網路頻寬瓶

作業系統:

  • 程式
  • 檔案系統
  • SWAP 分割槽
  • 核心引數調整
  • 應用程式(MySQL等):
  • mysqlreport 效能分析報告
  • mysqlsla 慢查詢日誌分析


4.效能調優

  • 確定調優目標
  • 具體調優步驟
  • 檢測調優結果

確定調優目標

   效能最佳化的目標是網站效能提高10%還是20%,不能老大說今天你給我最佳化一下網站效能,你就能使用網站效能翻一倍。

   首先,要問他我們需要達到一個怎麼的目標。然後,要了解一下整個環境(架構)包括程式碼(當然需要了解一下業務邏輯,大致瞭解一下,肯定沒壞處),有時間多和開發溝通一下,問問程式碼中有多少坑要填,這很重要。往往他們最佳化一下程式碼中的SQL查詢,比你最佳化系統多少天都來的有效果,哈哈。

具體調優步驟

  • 如果你不懂系統的引數,千萬不要對系統的引數進行隨意的改動,不然會後悔。
  • 每次只對一種系統資源進行系統除錯,如CPU、或記憶體、磁碟。
  • 每次改動儘量少的引數設定,推薦每次修改一個設定。
  • 分析一項系統資源時,使用多種工具,往往會有意想不到的結果。
  • 不及勝於過之(寧願少做一點,不要做過頭了,效能已達到要求就不要隨意亂動,做好你的監控)。

檢測調優結果

每次效能調優後必須對效能程式檢測,如Web伺服器的ab工具,就是一個很好的檢測工具,每次調優後都能看到具體的變化。

5.效能監控

效能監控這個很重要,具體包括:伺服器的效能監控和具體服務的效能監控。下面說一說具體有哪些效能監控指標:

伺服器的效能監控

  • CPU 使用率
  • CPU負載
  • 記憶體使用率
  • 磁碟I/O
  • 網路流量
  • 磁碟空間
  • 系統程式

服務的效能監控(MySQL)

  • MySQL查詢吞吐率,包括Change DB、Select、Insert、Update、Delete
  • MySQL持久連線利用率
  • MySQL查詢快取空間使用率
  • MySQL查詢快取命中率
  • MySQL快取查詢數
  • MySQL索引快取命中率
  • MySQL索引讀取統計
  • MySQL連線吞吐率
  • MySQL連線快取命中率
  • MySQL併發連線數,包括最大允許連線數、實際最大連線數、當前連線數、活躍連線數、快取連線數
  • MySQL流量統計
  • MySQL表統計鎖定


八、總結

   在這篇“效能最佳化概述”的博文中只是給大家講解一下具體的最佳化思路,幫助大家理解效能最佳化,這樣就會更容易理解一些,讓大家知道效能最佳化並不是傳說中的那麼難,難到不可動手去做,只要我們掌握好方法,什麼難題都可以解決。好了,說了這麼多。希望大家有所收穫吧^_^……

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9034054/viewspace-2063972/,如需轉載,請註明出處,否則將追究法律責任。

相關文章