一、概述

1.1 背景介紹

在實際生產(chǎn)環(huán)境中，系統(tǒng)性能問題往往來得突然又難以定位。某天下午，你可能會接到告警：電商平臺響應時間從平時的200ms突然飆升到2秒，用戶投訴激增，運營團隊焦急萬分。這時候，如何快速準確地找到性能瓶頸，就成了運維工程師的核心能力。

性能問題的表現(xiàn)形式多種多樣：應用響應緩慢、頁面加載卡頓、API接口超時、數(shù)據(jù)庫查詢變慢等等。但歸根結(jié)底，這些問題通常源于三大系統(tǒng)資源的瓶頸：CPU、內(nèi)存、磁盤IO。

很多時候，我們?nèi)菀紫萑?頭痛醫(yī)頭、腳痛醫(yī)腳"的誤區(qū)?？吹紺PU使用率高就加CPU，看到內(nèi)存不足就加內(nèi)存，結(jié)果錢花了不少，問題依然存在。實際上，性能優(yōu)化需要系統(tǒng)化的診斷方法，要理解各個資源之間的關聯(lián)關系。比如，磁盤IO慢可能導致進程等待，進而引發(fā)CPU的iowait升高；內(nèi)存不足會觸發(fā)頻繁的頁面交換，同樣會拖累磁盤IO性能。

本文將介紹一套完整的性能診斷方法論，從整體到局部，從現(xiàn)象到本質(zhì)，幫助你快速定位系統(tǒng)瓶頸。這套方法基于Linux系統(tǒng)自帶的工具，無需額外安裝復雜的監(jiān)控系統(tǒng)，就能在生產(chǎn)環(huán)境中快速排查問題。

1.2 技術(shù)特點

系統(tǒng)化診斷流程：采用"自頂向下"的分析思路，先看整體資源使用情況，再深入到具體進程和線程。避免盲目優(yōu)化，確保每一步都有數(shù)據(jù)支撐。通過建立性能基線，對比歷史數(shù)據(jù)，能夠快速識別異常波動。

多維度性能指標：不僅僅關注CPU使用率、內(nèi)存占用這些表面指標，更要深入分析上下文切換、緩存命中率、IO等待時間等深層指標。這些指標往往能揭示性能問題的真正原因。比如，CPU使用率只有50%，但上下文切換頻率極高，說明存在嚴重的線程競爭問題。

工具鏈完整實用：Linux系統(tǒng)內(nèi)置了一整套性能分析工具（top、vmstat、iostat、mpstat、pidstat等），這些工具經(jīng)過多年驗證，穩(wěn)定可靠。掌握這些工具的使用方法，就能應對90%以上的性能問題。更重要的是，這些工具開銷很小，可以在生產(chǎn)環(huán)境中放心使用。

1.3 適用場景

場景一：Web應用服務器性能優(yōu)化典型表現(xiàn)是高并發(fā)時響應時間顯著增加。比如電商平臺在促銷活動期間，用戶訪問量激增，服務器CPU使用率飆升到90%以上，大量請求超時。通過診斷發(fā)現(xiàn)，問題可能出在應用線程池配置不合理，導致頻繁的上下文切換；也可能是某個接口存在性能問題，占用了大量CPU資源。診斷重點包括：CPU各核心的使用分布、進程和線程的CPU占用、系統(tǒng)調(diào)用開銷、上下文切換頻率等。優(yōu)化方向可能是調(diào)整線程池大小、優(yōu)化代碼邏輯、增加緩存、或者進行水平擴展。

場景二：數(shù)據(jù)庫服務器瓶頸定位數(shù)據(jù)庫是很多系統(tǒng)的核心，一旦出現(xiàn)性能問題，影響面會非常大。常見表現(xiàn)是查詢變慢、事務堆積、連接數(shù)打滿。通過診斷可能發(fā)現(xiàn)：磁盤IO性能不足，大量慢查詢導致磁盤讀寫壓力大；內(nèi)存配置不當，緩沖池太小導致緩存命中率低；或者是CPU瓶頸，復雜查詢消耗大量計算資源。診斷重點包括：磁盤IO的吞吐量和延遲、內(nèi)存緩沖池的使用情況、慢查詢?nèi)罩痉治觥㈡i等待情況等。優(yōu)化方向可能是添加索引、優(yōu)化查詢語句、調(diào)整數(shù)據(jù)庫配置參數(shù)、升級硬件（特別是使用SSD替換機械硬盤）。

場景三：批處理任務性能分析很多企業(yè)都有定時運行的批處理任務，比如數(shù)據(jù)同步、報表生成、日志分析等。這類任務的特點是運行時間長、資源占用集中。如果任務執(zhí)行時間從原來的1小時增加到4小時，就需要分析是哪個環(huán)節(jié)出了問題?？赡苁荂PU密集型任務（如數(shù)據(jù)計算、加密解密），也可能是IO密集型任務（如大文件讀寫、數(shù)據(jù)庫批量插入）。診斷重點包括：任務的資源使用特征、是否存在資源競爭、磁盤IO模式（順序讀寫還是隨機讀寫）等。優(yōu)化方向可能是并行處理、調(diào)整IO調(diào)度策略、使用更快的存儲設備、或者優(yōu)化算法減少計算量。

1.4 環(huán)境要求

二、詳細步驟

2.1 準備工作

2.1.1 系統(tǒng)檢查

在開始性能診斷之前，需要先了解系統(tǒng)的基本配置信息，建立一個清晰的認知基礎。

# 查看系統(tǒng)版本和內(nèi)核信息
cat /etc/os-release
uname -a

# 查看CPU信息
lscpu
nproc # 快速查看CPU核心數(shù)

# 查看內(nèi)存信息
free -h
cat /proc/meminfo | head -20

# 查看磁盤信息
df -h
lsblk

說明：這些命令幫助我們了解硬件配置的基本情況。比如，一個8核16G內(nèi)存的服務器和一個2核4G的服務器，性能診斷的關注點會有很大不同。CPU核心數(shù)決定了系統(tǒng)的并行處理能力，內(nèi)存大小影響緩存策略，磁盤類型（SSD還是HDD）直接關系到IO性能。

2.1.2 安裝依賴工具

大部分Linux發(fā)行版默認已經(jīng)安裝了基礎的性能工具，但sysstat包可能需要手動安裝。

# Ubuntu/Debian系統(tǒng)
sudo apt update
sudo apt install -y sysstat

# CentOS/RHEL系統(tǒng)
sudo yum install -y sysstat

# 驗證安裝
iostat -V
mpstat -V
pidstat -V

工具說明：

top/htop：實時查看進程資源占用，系統(tǒng)自帶

vmstat：虛擬內(nèi)存統(tǒng)計，查看系統(tǒng)整體性能

iostat：磁盤IO性能分析，來自sysstat包

mpstat：多處理器統(tǒng)計，分析每個CPU核心的使用情況

pidstat：進程級性能統(tǒng)計，精確定位問題進程

這些工具的共同特點是：輕量級、開銷小、輸出直觀。在生產(chǎn)環(huán)境中使用不會對系統(tǒng)造成明顯影響。

2.2 CPU性能診斷

2.2.1 快速查看CPU整體狀況

當接到性能告警時，第一步是快速了解CPU的整體使用情況。

# 使用top查看實時CPU使用情況
top

# 或者使用uptime查看系統(tǒng)負載
uptime

# 查看CPU平均負載
cat /proc/loadavg

輸出示例：

top - 1415 up 45 days, 3:21, 2 users, load average: 4.52, 3.89, 2.76
Tasks: 245 total,  3 running, 242 sleeping,  0 stopped,  0 zombie
%Cpu(s): 78.5 us, 12.3 sy, 0.0 ni, 5.2 id, 3.8 wa, 0.0 hi, 0.2 si, 0.0 st

關鍵指標解讀：

load average：系統(tǒng)平均負載，三個數(shù)字分別代表1分鐘、5分鐘、15分鐘的平均值。一般來說，負載值不應超過CPU核心數(shù)。如果是8核CPU，負載長期超過8就需要關注了。

us（user）：用戶空間CPU使用率，應用程序消耗的CPU

sy（system）：內(nèi)核空間CPU使用率，系統(tǒng)調(diào)用消耗的CPU

id（idle）：空閑CPU百分比

wa（iowait）：等待IO的CPU時間，這個值高說明磁盤IO可能是瓶頸

實戰(zhàn)經(jīng)驗：如果看到iowait超過20%，基本可以判斷是磁盤IO問題，而不是CPU計算能力不足。這時候繼續(xù)優(yōu)化CPU是沒用的，應該轉(zhuǎn)向磁盤IO診斷。

2.2.2 查看每個CPU核心的使用情況

現(xiàn)代服務器都是多核CPU，有時候會出現(xiàn)負載不均衡的情況，某些核心跑滿了，其他核心卻很空閑。

# 查看每個CPU核心的使用率
mpstat -P ALL 1 5

# 或者使用top然后按1鍵查看各核心情況

輸出示例：

1430   CPU  %usr  %nice  %sys %iowait  %irq  %soft %steal %guest %gnice  %idle
1431   all  45.23  0.00  10.52  2.15  0.00  0.25  0.00  0.00  0.00  41.85
1431    0  89.00  0.00  11.00  0.00  0.00  0.00  0.00  0.00  0.00  0.00
1431    1  42.00  0.00  8.00  5.00  0.00  1.00  0.00  0.00  0.00  44.00
1431    2  38.00  0.00  12.00  3.00  0.00  0.00  0.00  0.00  0.00  47.00
1431    3  12.00  0.00  5.00  1.00  0.00  0.00  0.00  0.00  0.00  82.00

分析要點：上面的例子中，CPU 0的使用率達到89%，而CPU 3只有18%，說明負載分布不均。這可能是因為：

應用程序是單線程的，無法利用多核

進程CPU親和性設置不當，綁定到了特定核心

某個進程占用了大量CPU資源

2.2.3 定位高CPU占用的進程

找到了CPU使用率高，下一步就是定位具體是哪個進程在消耗CPU。

# 使用top查看進程CPU占用，按P鍵按CPU排序
top

# 或者使用ps命令
ps aux --sort=-%cpu | head -10

# 使用pidstat查看進程CPU使用情況（推薦）
pidstat -u 1 5

pidstat輸出示例：

1415   UID    PID  %usr %system %guest  %wait  %CPU  CPU Command
1416    0   1234  85.00  10.00  0.00  0.00  95.00   0 java
1416   1000   5678  12.00  3.00  0.00  0.00  15.00   1 nginx
1416    0   9012  8.00  2.00  0.00  0.00  10.00   2 mysqld

說明：從上面可以看到，PID為1234的java進程占用了95%的CPU，這就是需要重點關注的對象。

2.2.4 分析上下文切換

CPU使用率不高，但系統(tǒng)響應慢？可能是上下文切換過于頻繁。

# 使用vmstat查看上下文切換
vmstat 1 5

# 查看每個進程的上下文切換情況
pidstat -w 1 5

vmstat輸出示例：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b  swpd  free  buff cache  si  so  bi  bo in cs us sy id wa st
4 0   0 512340 89532 1024576  0  0   2  15 2500 45000 45 10 43 2 0

關鍵指標：

cs（context switch）：每秒上下文切換次數(shù)。正常情況下幾千到一萬次，如果超過5萬次就需要關注

in（interrupts）：每秒中斷次數(shù)

實戰(zhàn)案例：某電商平臺在促銷期間，應用響應變慢，CPU使用率只有60%。通過vmstat發(fā)現(xiàn)cs值達到8萬次/秒，遠超正常水平。進一步排查發(fā)現(xiàn)是應用線程池配置過大（500個線程），導致大量線程競爭CPU，頻繁切換。將線程池調(diào)整為100后，上下文切換降到2萬次/秒，響應時間恢復正常。

2.3 內(nèi)存性能診斷

2.3.1 查看內(nèi)存使用概況

內(nèi)存問題往往比CPU問題更隱蔽，但影響更嚴重。一旦內(nèi)存不足觸發(fā)swap，系統(tǒng)性能會斷崖式下降。

# 查看內(nèi)存使用情況
free -h

# 查看詳細內(nèi)存信息
cat /proc/meminfo | head -30

# 使用vmstat查看內(nèi)存和swap情況
vmstat 1 5

free命令輸出示例：

       total    used    free   shared buff/cache  available
Mem:      15Gi    8.2Gi    1.5Gi    256Mi    5.8Gi    6.5Gi
Swap:     2.0Gi    512Mi    1.5Gi

關鍵指標解讀：

total：總內(nèi)存大小

used：已使用內(nèi)存（不包括buff/cache）

free：完全空閑的內(nèi)存

buff/cache：用于緩沖和緩存的內(nèi)存，可以被回收

available：真正可用的內(nèi)存，這是最重要的指標

Swap used：交換分區(qū)使用量，如果這個值不為0，說明內(nèi)存已經(jīng)不夠用了

重要提示：很多人看到used很高就以為內(nèi)存不足，其實不然。Linux會盡可能利用空閑內(nèi)存做緩存，這是正常的。真正需要關注的是available這一列，只要這個值足夠大，系統(tǒng)就不會有內(nèi)存壓力。

2.3.2 識別內(nèi)存泄漏

內(nèi)存泄漏是Web應用常見的問題，表現(xiàn)為內(nèi)存使用持續(xù)增長，最終導致OOM（Out of Memory）。

# 查看進程內(nèi)存占用排序
ps aux --sort=-%mem | head -10

# 使用pidstat查看進程內(nèi)存使用
pidstat -r 1 5

# 查看進程的詳細內(nèi)存映射
pmap -x 

pidstat輸出示例：

1420   UID    PID minflt/s majflt/s   VSZ   RSS  %MEM Command
1421    0   1234  125.00   0.00 8192000 4096000 25.60 java
1421   1000   5678   45.00   0.00 2048000  512000  3.20 nginx

關鍵指標：

VSZ：虛擬內(nèi)存大小，進程申請的總內(nèi)存

RSS：實際物理內(nèi)存占用，這是真正消耗的內(nèi)存

%MEM：內(nèi)存占用百分比

minflt/s：每秒次缺頁錯誤（minor page fault），從緩存中加載頁面

majflt/s：每秒主缺頁錯誤（major page fault），需要從磁盤加載，這個值高說明內(nèi)存不足

診斷內(nèi)存泄漏的方法：

# 持續(xù)監(jiān)控某個進程的內(nèi)存使用
watch -n 5"ps aux | grep java | grep -v grep"

# 或者使用腳本記錄內(nèi)存變化
whiletrue;do
  date >> mem_monitor.log
  ps aux | grep java | grep -v grep >> mem_monitor.log
  sleep 60
done

如果發(fā)現(xiàn)RSS持續(xù)增長，幾個小時內(nèi)從2G漲到8G，基本可以確定存在內(nèi)存泄漏。

2.3.3 監(jiān)控頁面交換（Swap）

Swap是內(nèi)存不足時的救命稻草，但也是性能殺手。一旦開始頻繁swap，系統(tǒng)性能會急劇下降。

# 查看swap使用情況
free -h | grep Swap

# 使用vmstat監(jiān)控swap活動
vmstat 1 10

# 查看哪些進程在使用swap
forfilein/proc/*/status;do
  awk'/VmSwap|Name/{printf $2 " " $3}END{ print ""}'$file
done| sort -k 2 -n -r | head -10

vmstat關鍵指標：

procs -----------memory---------- ---swap-- -----io----
r b  swpd  free  buff cache  si  so  bi  bo
2 1 524288 102400 45120 512000 120 250  50  100

si（swap in）：每秒從swap讀入內(nèi)存的數(shù)據(jù)量（KB）

so（swap out）：每秒從內(nèi)存寫入swap的數(shù)據(jù)量（KB）

判斷標準：如果si和so的值持續(xù)不為0，說明系統(tǒng)在頻繁進行頁面交換，這是嚴重的性能問題信號。

實戰(zhàn)案例：某社交平臺的應用服務器，用戶反饋頁面加載極慢。通過free命令發(fā)現(xiàn)swap使用了1.5G，vmstat顯示si和so值分別為200和150。進一步排查發(fā)現(xiàn)是Java應用的堆內(nèi)存配置過大（-Xmx12G），而服務器總內(nèi)存只有16G，導致系統(tǒng)內(nèi)存不足。將堆內(nèi)存調(diào)整為8G后，swap使用降為0，頁面響應恢復正常。

2.4 磁盤IO性能診斷

2.4.1 查看磁盤IO整體狀況

磁盤IO是很多性能問題的根源，特別是使用機械硬盤的服務器。

# 查看磁盤IO統(tǒng)計
iostat -x 1 5

# 查看磁盤使用情況
df -h

# 查看磁盤分區(qū)信息
lsblk

iostat輸出示例：

Device      r/s   w/s   rkB/s   wkB/s  await %util
sda       45.20  120.50  1024.00  4096.00  25.30 85.60
sdb       2.10   5.30   64.00  128.00  5.20 12.40

關鍵指標解讀：

r/s：每秒讀操作次數(shù)

w/s：每秒寫操作次數(shù)

rkB/s：每秒讀取的數(shù)據(jù)量（KB）

wkB/s：每秒寫入的數(shù)據(jù)量（KB）

await：平均IO等待時間（毫秒），這是最關鍵的指標

%util：磁盤使用率，接近100%說明磁盤已經(jīng)飽和

判斷標準：

await < 10ms：性能良好（SSD）

await 10-20ms：可以接受

await > 50ms：存在明顯IO瓶頸

%util > 80%：磁盤接近飽和

2.4.2 定位高IO進程

找到磁盤IO瓶頸后，需要定位是哪個進程在進行大量IO操作。

# 使用pidstat查看進程IO情況
pidstat -d 1 5

# 使用iotop實時查看進程IO（需要安裝）
sudo iotop -o

# 查看進程打開的文件
lsof -p 

pidstat輸出示例：

1520   UID    PID  kB_rd/s  kB_wr/s Command
1521    0   1234   0.00  8192.00 java
1521   999   5678  2048.00  512.00 mysqld

說明：從上面可以看到，PID 1234的java進程每秒寫入8MB數(shù)據(jù)，這可能是日志寫入或數(shù)據(jù)持久化操作。

2.4.3 分析IO模式

不同的IO模式對性能影響差異很大。順序IO性能遠高于隨機IO。

# 查看IO調(diào)度器
cat /sys/block/sda/queue/scheduler

# 查看磁盤隊列深度
cat /sys/block/sda/queue/nr_requests

# 使用iostat查看詳細IO統(tǒng)計
iostat -x -d 1 5

實戰(zhàn)案例：某內(nèi)容平臺的靜態(tài)資源服務器，用戶反饋圖片加載緩慢。通過iostat發(fā)現(xiàn)sda的await達到120ms，%util為95%。使用pidstat定位到nginx進程IO很高。進一步分析發(fā)現(xiàn)是大量小文件的隨機讀取導致磁盤IO瓶頸。解決方案是：1）將靜態(tài)資源遷移到SSD；2）啟用nginx的open_file_cache緩存文件句柄；3）使用CDN分流。優(yōu)化后await降到15ms，頁面加載速度提升5倍。

三、示例代碼和配置

3.1 完整診斷腳本

3.1.1 一鍵性能診斷腳本

這個腳本可以快速收集系統(tǒng)的CPU、內(nèi)存、磁盤IO等關鍵性能指標。

#!/bin/bash
# 文件名：perf_check.sh
# 功能：系統(tǒng)性能快速診斷工具

echo"========================================="
echo"系統(tǒng)性能診斷報告"
echo"時間：$(date '+%Y-%m-%d %H:%M:%S')"
echo"========================================="
echo""

# 1. 系統(tǒng)基本信息
echo"【系統(tǒng)信息】"
echo"主機名：$(hostname)"
echo"內(nèi)核版本：$(uname -r)"
echo"運行時間：$(uptime | awk -F'up ' '{print $2}' | awk -F',' '{print $1}')"
echo""

# 2. CPU信息
echo"【CPU信息】"
echo"CPU核心數(shù)：$(nproc)"
echo"系統(tǒng)負載：$(uptime | awk -F'load average:' '{print $2}')"
echo""
echo"CPU使用率（最近5秒平均）："
mpstat 1 5 | tail -1
echo""

# 3. 內(nèi)存信息
echo"【內(nèi)存信息】"
free -h
echo""
echo"Swap使用情況："
swapon --show
echo""

# 4. 磁盤IO信息
echo"【磁盤IO信息】"
iostat -x 1 3 | grep -E"Device|sd"
echo""

# 5. TOP進程
echo"【CPU占用TOP5進程】"
ps aux --sort=-%cpu | head -6
echo""

echo"【內(nèi)存占用TOP5進程】"
ps aux --sort=-%mem | head -6
echo""

echo"========================================="
echo"診斷完成"
echo"========================================="

使用方法：

chmod +x perf_check.sh
./perf_check.sh

3.2 實際應用案例

案例一：電商平臺高峰期CPU瓶頸

場景描述：某電商平臺在雙11促銷期間，下午2點開始用戶反饋頁面響應極慢，訂單提交失敗率激增。監(jiān)控顯示應用服務器響應時間從平時的200ms飆升到2000ms以上。

診斷過程：

快速查看系統(tǒng)負載

uptime
# 輸出：load average: 12.5, 10.8, 8.3
# 服務器是8核CPU，負載超過12說明有問題

查看CPU使用情況

top
# 發(fā)現(xiàn)CPU使用率達到95%，其中us占85%，sy占10%

定位高CPU進程

pidstat -u 1 5
# 發(fā)現(xiàn)tomcat進程（PID 1234）占用CPU 780%（多線程累加）

分析上下文切換

vmstat 1 5
# cs值達到85000次/秒，遠超正常水平

查看線程數(shù)

ps -eLf | grep java | wc -l
# 輸出：512個線程

問題根因：應用配置的線程池過大（maxThreads=500），在高并發(fā)下導致大量線程競爭CPU，頻繁的上下文切換反而降低了吞吐量。

解決方案：

# 1. 調(diào)整Tomcat配置
vim /opt/tomcat/conf/server.xml
# 修改：maxThreads="500" -> maxThreads="200"
# 修改：acceptCount="100" -> acceptCount="200"

# 2. 重啟應用
systemctl restart tomcat

# 3. 驗證效果
vmstat 1 10
# cs值降到25000次/秒
# CPU使用率降到70%，但響應時間恢復到300ms

優(yōu)化效果：

上下文切換從85000次/秒降到25000次/秒

CPU使用率從95%降到70%

響應時間從2000ms恢復到300ms

訂單成功率從60%提升到98%

案例二：社交平臺內(nèi)存泄漏導致OOM

場景描述：某社交平臺的API服務器，每隔2-3天就會自動重啟一次，查看日志發(fā)現(xiàn)是Java進程OOM（Out of Memory）。用戶在高峰期經(jīng)常遇到503錯誤。

診斷過程：

查看內(nèi)存使用情況

free -h
# 發(fā)現(xiàn)可用內(nèi)存只有200MB，swap使用了1.8G

監(jiān)控進程內(nèi)存變化

# 每小時記錄一次內(nèi)存使用
whiletrue;do
 echo"$(date)-$(ps aux | grep java | grep -v grep | awk '{print $6}')">> mem_track.log
  sleep 3600
done

分析內(nèi)存增長趨勢

cat mem_track.log
# 發(fā)現(xiàn)RSS從啟動時的2G，12小時后增長到14G

檢查swap使用

vmstat 1 10
# si和so值持續(xù)不為0，說明在頻繁swap

問題根因：應用存在內(nèi)存泄漏，長時間運行后內(nèi)存持續(xù)增長，最終觸發(fā)OOM。同時JVM堆內(nèi)存配置過大（-Xmx12G），在16G內(nèi)存的服務器上留給系統(tǒng)的空間太少。

解決方案：

# 1. 調(diào)整JVM參數(shù)
vim /opt/app/bin/startup.sh
# 修改：-Xmx12G -Xms12G -> -Xmx8G -Xms8G
# 添加：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/

# 2. 禁用swap（臨時措施）
sudo swapoff -a

# 3. 重啟應用并持續(xù)監(jiān)控
systemctl restart app
watch -n 300"free -h && ps aux | grep java"

后續(xù)優(yōu)化：通過分析heap dump文件，發(fā)現(xiàn)是緩存對象沒有正確釋放導致的內(nèi)存泄漏。修復代碼后，內(nèi)存使用穩(wěn)定在6G左右，不再增長。

四、最佳實踐和注意事項

4.1 最佳實踐

4.1.1 性能優(yōu)化建議

CPU優(yōu)化：

合理配置線程池大小，一般設置為CPU核心數(shù)的1-2倍

避免在高并發(fā)場景使用synchronized，考慮使用Lock或無鎖數(shù)據(jù)結(jié)構(gòu)

使用CPU親和性綁定關鍵進程到特定核心

# 將進程綁定到CPU 0-3
taskset -cp 0-3 

內(nèi)存優(yōu)化：

JVM堆內(nèi)存不要超過物理內(nèi)存的75%，留足夠空間給操作系統(tǒng)

監(jiān)控內(nèi)存使用趨勢，及時發(fā)現(xiàn)內(nèi)存泄漏

合理配置swappiness參數(shù)

# 降低swap傾向（推薦值10）
echo10 | sudo tee /proc/sys/vm/swappiness
# 永久生效
echo"vm.swappiness=10"| sudo tee -a /etc/sysctl.conf
sudo sysctl -p

磁盤IO優(yōu)化：

優(yōu)先使用SSD，性能提升10倍以上

調(diào)整IO調(diào)度器，SSD使用noop或none，HDD使用deadline

# 查看當前調(diào)度器
cat /sys/block/sda/queue/scheduler

# 修改為deadline
echodeadline | sudo tee /sys/block/sda/queue/scheduler

啟用文件系統(tǒng)緩存，減少磁盤訪問

對于數(shù)據(jù)庫，考慮將數(shù)據(jù)文件和日志文件放在不同磁盤

4.2 注意事項

4.2.1 診斷工具使用注意事項

采樣頻率不宜過高：

iostat、vmstat等工具的采樣間隔建議不低于1秒

過于頻繁的采樣會增加系統(tǒng)開銷，影響診斷結(jié)果的準確性

生產(chǎn)環(huán)境建議使用1-5秒的采樣間隔

正確理解指標含義：

CPU使用率高不一定是問題，要結(jié)合業(yè)務負載判斷

內(nèi)存used高是正常的，Linux會充分利用內(nèi)存做緩存

關注available而不是free

swap使用不為0不一定有問題，但si/so持續(xù)不為0就需要關注

避免過度優(yōu)化：

不要為了優(yōu)化而優(yōu)化，要有明確的性能目標

優(yōu)化前后要有數(shù)據(jù)對比，證明優(yōu)化有效

有些"優(yōu)化"可能會降低系統(tǒng)穩(wěn)定性

4.2.2 常見錯誤

五、故障排查和監(jiān)控

5.1 快速排查流程

當接到性能告警時，按照以下流程快速定位問題：

第一步：確認問題現(xiàn)象

# 查看系統(tǒng)負載和運行時間
uptime

# 快速查看資源使用情況
top

第二步：判斷瓶頸類型

# 如果CPU iowait高（>20%），是IO問題
# 如果CPU使用率高（>80%），是CPU問題
# 如果有swap活動，是內(nèi)存問題
vmstat 1 5

第三步：定位問題進程

# CPU問題
pidstat -u 1 5

# 內(nèi)存問題
pidstat -r 1 5

# IO問題
pidstat -d 1 5

第四步：深入分析

CPU問題：檢查線程數(shù)、上下文切換、是否有死循環(huán)

內(nèi)存問題：檢查是否內(nèi)存泄漏、配置是否合理

IO問題：檢查IO模式、磁盤類型、是否需要優(yōu)化

5.2 性能監(jiān)控指標

建議監(jiān)控的關鍵指標及告警閾值：

六、總結(jié)

6.1 技術(shù)要點回顧

系統(tǒng)化診斷方法：從整體到局部，先看top/uptime了解全局，再用mpstat/pidstat定位具體問題，最后深入分析

CPU診斷核心：關注使用率、負載、iowait、上下文切換四個維度，不要只看使用率

內(nèi)存診斷核心：重點看available而不是free，監(jiān)控swap活動，及時發(fā)現(xiàn)內(nèi)存泄漏

磁盤IO診斷核心：await和%util是關鍵指標，區(qū)分順序IO和隨機IO，SSD和HDD的優(yōu)化策略不同

6.2 進階學習方向

深入學習性能分析工具

學習perf、strace、ltrace等高級工具

掌握火焰圖（Flame Graph）的使用

了解eBPF技術(shù)在性能分析中的應用

應用層性能優(yōu)化

Java應用的JVM調(diào)優(yōu)

數(shù)據(jù)庫查詢優(yōu)化和索引設計

緩存策略和CDN使用

系統(tǒng)架構(gòu)優(yōu)化

負載均衡和水平擴展

微服務架構(gòu)下的性能優(yōu)化

容器化環(huán)境的性能監(jiān)控

6.3 參考資料

Linux Performance- Brendan Gregg的性能分析資源

sysstat官方文檔- iostat、mpstat等工具的詳細說明

Linux內(nèi)核文檔- /proc文件系統(tǒng)和性能相關接口

性能之巔- 系統(tǒng)性能優(yōu)化經(jīng)典書籍

附錄

A. 命令速查表

# CPU相關
top             # 實時查看進程資源占用
uptime           # 查看系統(tǒng)負載
mpstat -P ALL 1 5     # 查看每個CPU核心使用率
pidstat -u 1 5       # 查看進程CPU使用情況
vmstat 1 5         # 查看系統(tǒng)整體性能和上下文切換

# 內(nèi)存相關
free -h          # 查看內(nèi)存使用情況
vmstat 1 5         # 查看內(nèi)存和swap活動
pidstat -r 1 5       # 查看進程內(nèi)存使用
ps aux --sort=-%mem | head # 按內(nèi)存排序查看進程

# 磁盤IO相關
iostat -x 1 5       # 查看磁盤IO統(tǒng)計
pidstat -d 1 5       # 查看進程IO情況
df -h           # 查看磁盤空間使用
lsblk           # 查看磁盤分區(qū)信息

# 綜合診斷
dmesg | tail        # 查看內(nèi)核日志
lsof -p        # 查看進程打開的文件
strace -p       # 跟蹤進程系統(tǒng)調(diào)用

B. 性能基線參考值

8核16G內(nèi)存服務器（Web應用）：

CPU使用率：40-60%

系統(tǒng)負載：4-6

可用內(nèi)存：4-6G

磁盤IO await：<20ms（SSD）

上下文切換：10000-20000/s

16核32G內(nèi)存服務器（數(shù)據(jù)庫）：

CPU使用率：50-70%

系統(tǒng)負載：8-12

可用內(nèi)存：8-12G

磁盤IO await：<10ms（SSD）

上下文切換：15000-30000/s

C. 術(shù)語表