性能優(yōu)化是一個老生常談的話題，典型的性能問題如頁面響應慢、接口超時，服務器負載高、并發(fā)數(shù)低，數(shù)據(jù)庫頻繁死鎖等。尤其是在“糙快猛”的互聯(lián)網(wǎng)開發(fā)模式大行其道的今天，隨著系統(tǒng)訪問量的日益增加和代碼的臃腫，各種性能問題開始紛至沓來。在系統(tǒng)層面能夠影響應用性能的一般包括三個因素：CPU、內(nèi)存和IO，今天，我們先談談CPU性能的監(jiān)控以及調(diào)優(yōu)。
CPU性能監(jiān)控
當程序響應變慢的時候，首先使用top、vmstat、ps等命令查看系統(tǒng)的cpu使用率是否有異常，從而可以判斷出是否是cpu繁忙造成的性能問題。其中，主要通過us（用戶進程所占的%）這個數(shù)據(jù)來看異常的進程信息。當us接近100%甚至更高時，可以確定是cpu繁忙造成的響應緩慢。一般說來，cpu繁忙的原因有以下幾個：
- 線程中有無限空循環(huán)、無阻塞、正則匹配或者單純的計算
- 頻繁的gc
- 多線程頻繁的上下文切換
top命令
對于多個或多核cpu，上面的顯示則會是多個cpu所占用的百分比總合。如需查看每個核的消耗情況，可在進入top視圖后按1，就會按核來顯示cpu的使用情況，如上圖。
- us 表示用戶進程處理所占的百分比
- sy 表示為內(nèi)核線程處理所占的百分比
- ni 表示被nice命令改變優(yōu)先級的任務所占的百分比
- id 表示cpu的空閑時間所占的百分比
- wa 表示為在執(zhí)行過程中等待io所占的百分比
- hi 表示為硬件中斷所占的百分比
- si 表示為軟件中斷所占的百分比
- st 表示虛擬cpu等待實際cpu的時間的百分比
vmstat
- in 每秒CPU的中斷次數(shù)，包括時間中斷
- cs 每秒上下文切換次數(shù)，這個值要越小越好，太大了，要考慮調(diào)低線程或者進程的數(shù)目。每次調(diào)用系統(tǒng)函數(shù)，我們的代碼就會進入內(nèi)核空間，導致上下文切換，這個是很耗資源，也要盡量避免頻繁調(diào)用系統(tǒng)函數(shù)。上下文切換次數(shù)過多表示你的CPU大部分浪費在上下文切換，導致CPU干正經(jīng)事的時間少了，CPU沒有充分利用，是不可取的。
- us 用戶CPU時間。
- sy 系統(tǒng)CPU時間，如果太高，表示系統(tǒng)調(diào)用時間長，例如是IO操作頻繁。
- id 空閑 CPU時間，一般來說，id + us + sy = 100,一般我認為id是空閑CPU使用率，us是用戶CPU使用率，sy是系統(tǒng)CPU使用率。
- wt 等待IO CPU時間。
gstat -gcutil
如果發(fā)現(xiàn)是Java進程CPU占用過高，可以使用這個命令查看進程是不是正在頻繁GC，如下圖所示。
- S0 — Heap上的 Survivor space 0 區(qū)已使用空間的百分比
- S1 — Heap上的 Survivor space 1 區(qū)已使用空間的百分比
- E — Heap上的 Eden space 區(qū)已使用空間的百分比
- O — Heap上的 Old space 區(qū)已使用空間的百分比
- P — Perm space 區(qū)已使用空間的百分比
- YGC — 從應用程序啟動到采樣時發(fā)生 Young GC 的次數(shù)
- YGCT– 從應用程序啟動到采樣時 Young GC 所用的時間(單位秒)
- FGC — 從應用程序啟動到采樣時發(fā)生 Full GC 的次數(shù)
- FGCT– 從應用程序啟動到采樣時 Full GC 所用的時間(單位秒)
- GCT — 從應用程序啟動到采樣時用于垃圾回收的總時間(單位秒)
問題分析
根據(jù)上面提供的幾個常用命令，定位到問題以后，就可以根據(jù)具體問題分析其產(chǎn)生的原因了。
CPU瓶頸表現(xiàn)在兩個方面：用戶態(tài)CPU瓶頸和系統(tǒng)態(tài)CPU瓶頸。運行操作系統(tǒng)內(nèi)核以外的軟件時導致的瓶頸為用戶態(tài)CPU瓶頸，運行操作系統(tǒng)內(nèi)核的時候?qū)е碌钠款i為系統(tǒng)態(tài)CPU瓶頸。用戶態(tài)CPU和系統(tǒng)態(tài)CPU時間比率在3:1到4:1之間是正常的。如果在有瓶頸的系統(tǒng)中，用戶和系統(tǒng)時間比率高于這個區(qū)間，就應該分析用戶態(tài)CPU時間增加的原因。
us過高
當us值過高時，表示運行的應用消耗了大部分的cpu。在這種情況下，對于java應用而言，最重要的是找到具體消耗cpu的線程所執(zhí)行的代碼，可以采用如下方法。
1.使用gstat -gcutil查看JVM是否頻繁的進行GC。
2.如果根據(jù)gcutil查看，GC并不頻繁，請根據(jù)《當CPU飆高時，它在做什么》提供的方式，查看CPU在執(zhí)行什么代碼，來定位問題。
sy過高
當sy值過高時，使用vmstat來查看線程切換次數(shù)。很可能是linux花費了更多的時間在進行線程切換。java應用造成這種現(xiàn)象的主要原因是啟動的線程比較多， 且這些線程多處于不斷的阻塞（例如鎖等待，io等待）和執(zhí)行狀態(tài)的變化過程中，這就導致了操作系統(tǒng)要不斷的切換執(zhí)行的線程， 產(chǎn)生大量的上下文切換。在這種情況下，對java應用而言，最重要的是找出不斷切換狀態(tài)的原因， 可采用的方法為通過kill -3 pid 或jstack -l pid的方法dump出java應用程序的線程信息，查看線程的狀態(tài)信息以及鎖信息， 找出等待狀態(tài)或鎖競爭過多的線程。
CPU調(diào)優(yōu)
設置程序執(zhí)行的優(yōu)先級
可以使用nice和renice設置程序執(zhí)行的優(yōu)先級。
格式：nice [-n 數(shù)值] 命令nice 指令可以改變程序執(zhí)行的優(yōu)先權(quán)等級。指令讓使用者在執(zhí)行程序時，指定一個優(yōu)先等級，稱之為 nice 值。 這個數(shù)值從最高優(yōu)先級的-20到最低優(yōu)先級的19。負數(shù)值只有 root 才有權(quán)力使。 一般使用者，也可使用 nice 指令來做執(zhí)行程序的優(yōu)先級管理，但只能將nice值越調(diào)越高。
使用ulimit限制cpu占用時間
注意，ulimit 限制的是當前shell進程以及其派生的子進程。因此可以在腳本中調(diào)用ulimit來限制cpu使用時間。 例如，限制tar的cpu占用時間，單位秒。
ulimit -SHt 100 tar test.tar.gz test
如果tar占用時間超過了100秒，tar將會退出，這可能會導致打包不完全，因此不推薦使用ulimit對cpu占用時間進行限制。 另外，通過修改系統(tǒng)的/etc/security/limits配置文件，可以針對用戶進行限制。
使用程序自帶的對cpu使用調(diào)整的功能
某些程序自帶了對cpu使用調(diào)整的功能，比如nginx服務器，通過其配置文件，可以為工作進程指定cpu，如下：
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
這里0001 0010 0100 1000是掩碼，分別代表第1、2、3、4顆cpu核心，這就使得cpu的使用比較平均到每個核心上。
使用Nginx時，這種優(yōu)化方式是比較常見的。
相關閱讀：
本文首發(fā)在 劉振鋒的簡書博客 原文地址為《Linux系統(tǒng)CPU的性能監(jiān)控及調(diào)優(yōu)》轉(zhuǎn)載請注明！
