Linux效能調優從最佳化思路說起
平臺下有無數的開源軟體支撐,我們常見的apache、tomcat、mysql、php等等,開源軟體的最大理念是自由、開放,那麼linux作為一個開源平臺,最終要實現的是透過這些開源軟體的支援,以最低廉的成本,達到應用最優的效能。因此,談到效能問題,主要實現的是linux作業系統和應用程式的最佳結合。
一、效能問題綜述
系統的效能是指作業系統完成任務的有效性、穩定性和響應速度。Linux系統管理員可能經常會遇到系統不穩定、響應速度慢等問題,例如在linux上搭建了一個web服務,經常出現網頁無法開啟、開啟速度慢等現象,而遇到這些問題,就有人會抱怨linux系統不好,其實這些都是表面現象。作業系統完成一個任務時,與系統自身設定、網路拓樸結構、路由裝置、路由策略、接入裝置、物理線路等多個方面都密切相關,任何一個環節出現問題,都會影響整個系統的效能。因此當linux應用出現問題時,應當從應用程式、作業系統、伺服器硬體、網路環境等方面綜合排查,定位問題出現在哪個部分,然後集中解決。
在應用程式、作業系統、伺服器硬體、網路環境等方面,影響效能最大的是應用程式和作業系統兩個方面,因為這兩個方面出現的問題不易察覺,隱蔽性很強。而硬體、網路方面只要出現問題,一般都能馬上定位。下面主要講解作業系統方面的效能調優思路,應用程式方面需要具體問題具體對待。
以下從影響Linux效能的因素、分析效能涉及的人員、系統效能最佳化工具、系統效能評價標準四個方面介紹最佳化Linux的一般思路和方法。 推薦一個小程式:雲來米,雲伺服器方面需要輸入:KESS4HK, 可以提供免費的上雲技術諮詢和產品服務, 一個多雲平臺價格會比官網更低分傭
二、影響Linux效能的因素
2.1系統硬體資源
1.CPU
CPU是作業系統穩定執行的根本,CPU的速度與效能在很大程度上決定了系統整體的效能,因此,CPU數量越多、主頻越高,伺服器效能也就相對越好。但事實並非完全如此。
目前大部分CPU在同一時間內只能執行一個執行緒,超執行緒的處理器可以在同一時間執行多個執行緒,因此,可以利用處理器的超執行緒特性提高系統效能。在Linux系統下,只有執行SMP核心才能支援超執行緒,但是,安裝的CPU數量越多,從超執行緒獲得的效能方面的提高就越少。另外,Linux核心會把多核的處理器當作多個單獨的CPU來識別,例如兩個4核的CPU,在Lnux系統下會被當作8個單核CPU。但是從效能角度來講,兩個4核的CPU和8個單核的CPU並不完全等價,根據權威部門得出的測試結論,前者的整體效能要比後者低25%~30%。 推薦一個小程式 雲來米,輸入: KESS4HK ,運維技術分享及運維平時所需產品分析架構問題解決。
可能出現CPU瓶頸的應用有db伺服器、動態Web伺服器等,對於這類應用,要把CPU的配置和效能放在主要位置。
2.記憶體
記憶體的大小也是影響Linux效能的一個重要的因素,記憶體太小,系統程式將被阻塞,應用也將變得緩慢,甚至失去響應;記憶體太大,導致資源浪費。Linux系統採用了實體記憶體和虛擬記憶體兩種方式,虛擬記憶體雖然可以緩解實體記憶體的不足,但是佔用過多的虛擬記憶體,應用程式的效能將明顯下降,要保證應用程式的高效能執行,實體記憶體一定要足夠大;但是過大的實體記憶體,會造成記憶體資源浪費,例如,在一個32位處理器的Linux作業系統上,超過8GB的實體記憶體都將被浪費。因此,要使用更大的記憶體,建議安裝64位的作業系統,同時開啟Linux的大記憶體核心支援。 推薦一個小程式 雲來米,輸入: KESS4HK ,運維技術分享及運維平時所需產品分析架構問題解決。
由於處理器定址範圍的限制,在32位Linux作業系統上,應用程式單個程式最大隻能使用4GB的記憶體,這樣以來,即使系統有更大的記憶體,應用程式也無法“享”用,解決的辦法就是使用64位處理器,安裝64位作業系統。在64位作業系統下,可以滿足所有應用程式對記憶體的使用需求 ,幾乎沒有限制。 推薦一個小程式 雲來米,輸入: KESS4HK ,運維技術分享及運維平時所需產品分析架構問題解決。
可能出現記憶體效能瓶頸的應用有NOSQL伺服器、資料庫伺服器、快取伺服器等,對於這類應用要把記憶體大小放在主要位置。
3.磁碟I/O效能 推薦一個小程式 雲來米,輸入: KESS4HK ,運維技術分享及運維平時所需產品分析架構問題解決。
磁碟的I/O效能直接影響應用程式的效能,在一個有頻繁讀寫的應用中,如果磁碟I/O效能得不到滿足,就會導致應用停滯。好在現今的磁碟都採用了很多方法來提高I/O效能,比如常見的磁碟RAID技術。
透過RAID技術組成的磁碟組,就相當於一個大硬碟,使用者可以對它進行分割槽格式化、建立檔案系統等操作,跟單個物理硬碟一模一樣,唯一不同的是RAID磁碟組的I/O效能比單個硬碟要高很多,同時在資料的安全性也有很大提升。
根據磁碟組合方式的不同,RAID可以分為RAID0,RAID1、RAID2、RAID3、RAID4、RAID5、RAID6、RAID7、RAID0+1、RAID10等級別,常用的RAID級別有RAID0、RAID1、RAID5、RAID0+1,這裡進行簡單介紹。
? RAID 0:透過把多塊硬碟粘合成一個容量更大的硬碟組,提高了磁碟的效能和吞吐量。這種方式成本低,要求至少兩個磁碟,但是沒有容錯和資料修復功能,因而只能用在對資料安全性要求不高的環境中。
? RAID 1:也就是磁碟映象,透過把一個磁碟的資料映象到另一個磁碟上,最大限度地保證磁碟資料的可靠性和可修復性,具有很高的資料冗餘能力,但磁碟利用率只有50%,因而,成本最高,多用在儲存重要資料的場合。
? RAID5:採用了磁碟分段加奇偶校驗技術,從而提高了系統可靠性,RAID5讀出效率很高,寫入效率一般,至少需要3塊盤。允許一塊磁碟故障,而不影響資料的可用性。
? RAID0+1:把RAID0和RAID1技術結合起來就成了RAID0+1,至少需要4個硬碟。此種方式的資料除分佈在多個盤上外,每個盤都有其映象盤,提供全冗餘能力,同時允許一個磁碟故障,而不影響資料可用性,並具有快速讀/寫能力。
透過了解各個RAID級別的效能,可以根據應用的不同特性,選擇適合自身的RAID級別,從而保證應用程式在磁碟方面達到最優效能。
4.網路寬頻
Linux下的各種應用,一般都是基於網路的,因此網路頻寬也是影響效能的一個重要因素,低速的、不穩定的網路將導致網路應用程式的訪問阻塞,而穩定、高速的網路頻寬,可以保證應用程式在網路上暢通無阻地執行。幸運的是,現在的網路一般都是千兆頻寬或光纖網路,頻寬問題對應用程式效能造成的影響也在逐步降低。 推薦一個小程式:雲來米,雲伺服器方面需要輸入:KESS4HK, 可以提供免費的上雲技術諮詢和產品服務, 一個多雲平臺價格會比官網更低分傭
2.2 作業系統相關資源
基於作業系統的效能最佳化也是多方面的,可以從系統安裝、系統核心引數、網路引數、檔案系統等幾個方面進行衡量,下面依次進行簡單介紹。
1.系統安裝最佳化
系統最佳化可以從安裝作業系統開始,當安裝Linux系統時,磁碟的劃分,SWAP記憶體的分配都直接影響以後系統的執行效能,例如,磁碟分配可以遵循應用的需求:對於對寫操作頻繁而對資料安全性要求不高的應用,可以把磁碟做成RAID 0;而對於對資料安全性較高,對讀寫沒有特別要求的應用,可以把磁碟做成RAID 1;對於對讀操作要求較高,而對寫操作無特殊要求,並要保證資料安全性的應用,可以選擇RAID 5;對於對讀寫要求都很高,並且對資料安全性要求也很高的應用,可以選擇RAID10/01。這樣透過不同的應用需求設定不同的RAID級別,在磁碟底層對系統進行最佳化操作。
隨著記憶體價格的降低和記憶體容量的日益增大,對虛擬記憶體SWAP的設定,現在已經沒有了所謂虛擬記憶體是實體記憶體兩倍的要求,但是SWAP的設定還是不能忽略,根據經驗,如果記憶體較小(實體記憶體小於4GB),一般設定SWAP交換分割槽大小為記憶體的2倍;如果實體記憶體大於8GB小於16GB,可以設定SWAP大小等於或略小於實體記憶體即可;如果記憶體大小在16GB以上,原則上可以設定SWAP為0,但並不建議這麼做,因為設定一定大小的SWAP還是有一定作用的。
2.核心引數最佳化
系統安裝完成後,最佳化工作並沒有結束,接下來還可以對系統核心引數進行最佳化,不過核心引數的最佳化要和系統中部署的應用結合起來整體考慮。例如,如果系統部署的是Oracle資料庫應用,那麼就需要對系統共享記憶體段(kernel.shmmax、kernel.shmmni、kernel.shmall)、系統訊號量(kernel.sem)、檔案控制程式碼(fs.file-max)等引數進行最佳化設定;如果部署的是Web應用,那麼就需要根據Web應用特性進行網路引數的最佳化,例如修改net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse、net.core.somaxconn等網路核心引數。
3.檔案系統最佳化
檔案系統的最佳化也是系統資源最佳化的一個重點,在Linux下可選的檔案系統有ext2、ext3、ReiserFS、ext4、xfs,根據不同的應用,選擇不同的檔案系統。
Linux標準檔案系統是從VFS開始的,然後是ext,接著就是ext2,應該說,ext2是Linux上標準的檔案系統,ext3是在ext2基礎上增加日誌形成的,從VFS到ext4,其設計思想沒有太大變化,都是早期UNIX家族基於超級塊和inode的設計理念。
XFS檔案系統是一個高階日誌檔案系統,XFS透過分佈處理磁碟請求、定位資料、保持Cache 的一致性來提供對檔案系統資料的低延遲、高頻寬的訪問,因此,XFS極具伸縮性,非常健壯,具有優秀的日誌記錄功能、可擴充套件性強、快速寫入效能等優點。
目前伺服器端ext4和xfs是主流檔案系統,如何選擇合適的檔案系統,需要根據檔案系統的特點加上業務的需求綜合來定。
2.3 、應用程式軟體資源
應用程式的最佳化其實是整個最佳化工程的核心,如果一個應用程式存在BUG,那麼即使所有其他方面都達到了最優狀態,整個應用系統還是效能低下,所以,對應用程式的最佳化是效能最佳化過程的重中之重,這就對程式架構設計人員和程式開發人員提出了更高的要求。
三、 分析系統效能涉及的人員
3.1、Linux運維人員
在做效能最佳化過程中,Linux運維人員承擔著很重要的任務,首先,Linux運維人員要了解和掌握作業系統的當前執行狀態,例如系統負載、記憶體狀態、程式狀態、CPU負荷等資訊,這些資訊是檢測和判斷系統效能的基礎和依據;其次,Linux運維人員還有掌握系統的硬體資訊,例如磁碟I/O、CPU型號、記憶體大小、網路卡頻寬等引數資訊,然後根據這些資訊綜合評估系統資源的使用情況;第三,作為一名Linux運維人員,還要掌握應用程式對系統資源的使用情況,更深入的一點就是要了解應用程式的執行效率,例如是否有程式BUG、記憶體溢位等問題,透過對系統資源的監控,就能發現應用程式是否存在異常,如果確實是應用程式存在問題,需要把問題立刻反映給程式開發人員,進而改進或升級程式。
效能最佳化本身就是一個複雜和繁瑣的過程,Linux運維人員只有瞭解了系統硬體資訊、網路資訊、作業系統配置資訊和應用程式資訊才能有針對性地的展開對伺服器效能最佳化,這就要求Linux運維人員有充足的理論知識、豐富的實戰經驗以及縝密分析問題的頭腦。
3.2、系統架構設計人員
系統效能最佳化涉及的第二類人員就是應用程式的架構設計人員。如果Linux運維人員在經過綜合判斷後,發現影響效能的是應用程式的執行效率,那麼程式架構設計人員就要及時介入,深入瞭解程式執行狀態。首先,系統架構設計人員要跟蹤瞭解程式的執行效率,如果執行效率存在問題,要找出哪裡出現了問題;其次,如果真的是架構設計出現了問題,那麼就要馬上最佳化或改進系統架構,設計更好的應用系統架構。
3.3、軟體開發人員
系統效能最佳化最後一個環節涉及的是程式開發人員,在Linux運維人員或架構設計人員找到程式或結構瓶頸後,程式開發人員要馬上介入進行相應的程式修改。修改程式要以程式的執行效率為基準,改程式序的邏輯,有針對性地進行程式碼最佳化。例如,Linux運維人員在系統中發現有條SQL語句耗費大量的系統資源,抓取這條執行的SQL語句,發現此SQL語句的執行效率太差,是開發人員編寫的程式碼執行效率低造成的,這就需要把這個資訊反饋給開發人員,開發人員在收到這個問題後,可以有針對性的進行SQL最佳化,進而實現程式程式碼的最佳化。
從上面這個過程可以看出,系統效能最佳化一般遵循的流程是:首先Linux運維人員檢視系統的整體狀況,主要從系統硬體、網路裝置、作業系統配置、應用程式架構和程式程式碼五個方面進行綜合判斷,如果發現是系統硬體、網路裝置或者作業系統配置問題,Linux運維人員可以根據情況自主解決;如果發現是程式結構問題,就需要提交給程式架構設計人員;如果發現是程式程式碼執行問題,就交給開發人員進行程式碼最佳化。這樣就完成了一個系統效能最佳化的過程。
四、調優總結
系統效能最佳化是個涉及面廣、繁瑣、長久的工作,尋找出現效能問題的根源往往是最難的部分,一旦找到出現問題的原因,效能問題也就迎刃而解。因此,解決問題的思路變得非常重要。
例如,linux系統下的一個網站系統,使用者反映,網站訪問速度很慢,有時無法訪問。
針對這個問題,第一步要做的是檢測網路,可以透過ping命令檢查網站的域名解析是否正常,同時,ping伺服器地址的延時是否過大等等,透過這種方式,首先排除網路可能出現的問題;如果網路沒有問題,接著進入第二步,對linux系統的記憶體使用狀況進行檢查,因為網站響應速度慢,一般跟記憶體關聯比較大,透過free、vmstat等命令判斷記憶體資源是否緊缺,如果記憶體資源不存在問題,進入第三步,檢查系統CPU的負載狀況,可以透過sar、vmstat、top等命令的輸出綜合判斷CPU是否存在過載問題,如果CPU沒有問題,繼續進入第四步,檢查系統的磁碟I/O是否存在瓶頸,可以透過iostat、vmstat等命令檢查磁碟的讀寫效能,如果磁碟讀寫也沒有問題,linux系統自身的效能問題基本排除,最後要做的是檢查程式本身是否存在問題。透過這樣的思路,層層檢測,步步排查,效能問題就“無處藏身”,查詢出現效能問題的環節也就變得非常簡單。
本文轉自:https://blog.51cto.com/ixdba/2397749 作者:南非螞蟻
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982098/viewspace-2716205/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 主從延遲調優思路
- 效能調優——SQL最佳化SQL
- 技能篇:linux服務效能問題排查及jvm調優思路LinuxJVM
- linux調優效能命令Linux
- 微信小程式調起鍵盤效能優化微信小程式優化
- linux 效能調優引數Linux
- TiDB 效能分析&效能調優&最佳化實踐大全TiDB
- Linux系統效能調優之效能分析Linux
- Linux效能調優命令之freeLinux
- Linux系統效能調優技巧Linux
- K8S 效能最佳化 - OS sysctl 調優K8S
- (1)Linux效能調優之Linux程式管理Linux
- Linux效能及調優指南:程式管理Linux
- 從 JSON 說起JSON
- 從Promise的Then說起Promise
- Linux核心調優部分引數說明Linux
- Spark效能最佳化篇三:資料傾斜調優Spark
- Java 效能調優:最佳化 GC 執行緒設定JavaGC執行緒
- 說說Spark應用程式的效能調優(分散式計算引擎)Spark分散式
- Spark 效能調優--資源調優Spark
- Spark 效能調優--Shuffle調優 SortShuffleManagerSpark
- JAVA效能優化思路探究Java優化
- 【Java效能優化思路方向】Java優化
- 從Purge機制說起,詳解GaussDB(for MySQL)的最佳化策略MySql
- 【效能調優】效能測試、分析與調優基礎
- Linux伺服器效能分析與調優Linux伺服器
- linux 效能監控分析以及調優(top)Linux
- ElasticSearch效能調優Elasticsearch
- Nginx 效能調優Nginx
- iOS效能調優iOS
- php效能調優PHP
- Java效能調優Java
- Spark效能調優Spark
- oracle效能調優Oracle
- SQL 調優一般思路SQL
- Impala 5.7效能最佳化系列-10大最佳化思路
- iOS逆向——從RSA說起iOS
- 從程式猿入行說起