確認負載高的問題類型

查看當前負載：

uptime   # 顯示1/5/15分鐘負載平均值
top      # 查看實時負載（Load Average行）及CPU使用率

負載值的合理范圍：建議5分鐘負載 ≤ CPU邏輯核心數(shù)。若持續(xù)高于核心數(shù)，需深入排查。

檢查CPU使用情況

查看CPU整體使用率：

top       # 按`1`顯示多核CPU詳情，觀察us（用戶態(tài)）、sy（內(nèi)核態(tài)）、wa（I/O等待）等指標
vmstat 1  # 查看上下文切換（cs）、中斷（in）等

高us：用戶進程占用高，需排查具體進程。

高sy：內(nèi)核態(tài)占用高，可能是系統(tǒng)調(diào)用頻繁或中斷異常。

高wa：I/O等待高，可能磁盤或網(wǎng)絡瓶頸（需結合I/O排查）。

定位高CPU進程：

1. top中按P（按CPU排序）或M（按內(nèi)存排序）。
2. 記錄占用最高的PID（進程ID）。

分析進程內(nèi)線程：

top -Hp [PID]        # 查看指定進程的線程CPU占用
printf "%x\n" [TID] # 將線程ID轉(zhuǎn)為16進制（用于后續(xù)分析）

深入分析代碼熱點：

perf top -p [PID]    # 查看進程的函數(shù)級CPU消耗（需安裝perf）
strace -p [PID]      # 跟蹤系統(tǒng)調(diào)用（排查頻繁調(diào)用）

檢查I/O瓶頸

查看磁盤I/O負載：

iostat -x 1          # 觀察%util（設備利用率）、await（I/O等待時間）
iotop                # 按進程查看磁盤I/O使用

高%util：磁盤繁忙，可能頻繁讀寫或硬件性能不足。

高await：I/O響應慢，可能磁盤故障或配置問題。

檢查文件系統(tǒng)狀態(tài)：

df -h                # 查看磁盤空間是否耗盡
dmesg | grep -i error# 檢查磁盤錯誤日志

內(nèi)存與Swap分析

查看內(nèi)存使用：

free -h             # 查看物理內(nèi)存和Swap使用
top                 # 按`M`排序內(nèi)存占用進程

• Swap頻繁使用：物理內(nèi)存不足，需優(yōu)化內(nèi)存或擴容。
• OOM Killer觸發(fā)：檢查dmesg是否有OOM日志。

排查僵尸進程和異常進程

檢查僵尸進程：

ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'  # 列出僵尸進程

僵尸進程需終止其父進程（通過kill -9 [PPID]）。

檢查異常進程：

ps aux | grep [可疑進程名]
lsof -p [PID]       # 查看進程打開的文件和網(wǎng)絡連接

網(wǎng)絡瓶頸排查

查看網(wǎng)絡流量：

sar -n DEV 1        # 實時監(jiān)控網(wǎng)絡接口流量
netstat -antp       # 查看TCP連接狀態(tài)

其他工具

sar（歷史數(shù)據(jù)分析）：

sar -q              # 查看歷史負載趨勢
sar -u             # 查看歷史CPU使用率

系統(tǒng)日志：

journalctl -f      # 實時查看系統(tǒng)日志
cat /var/log/messages | grep -i error

查看磁盤狀態(tài)

通過命令查看磁盤IO較高

iostat -xd 2

高I/O負載設備

sda 磁盤：

• %util：首次采樣達 63.03%，后續(xù)波動在 12.45%~29.80%，但最后一次采樣中 dm-0 的 %util 達 100%（參考輸出第二組數(shù)據(jù)）。
• 讀寫吞吐：首次采樣 rkB/s=126,551.57（約 123.6 MB/s），說明大量讀操作。
• 隊列積壓：avgqu-sz 首次采樣為 31.26（高隊列積壓），await 首次達 18ms（I/O延遲較高）。

邏輯卷 dm-0/dm-2：

• dm-0：首次采樣 rkB/s=32,555.22（約 31.8 MB/s），%util=40.64%。
• dm-2：首次采樣 rkB/s=93,990.45（約 91.8 MB/s），%util=54.94%，讀寫請求密集。

問題定位

• I/O瓶頸：%util 多次超過 70%（如 dm-0 達 100%），表明磁盤已飽和，請求排隊嚴重。
• 高讀操作：rkB/s 和 r/s 顯著偏高，可能是頻繁讀取大文件或數(shù)據(jù)庫全表掃描導致。

排查步驟

定位高I/O進程

使用 iotop 或 pidstat 直接查看實時I/O占用：

iotop -o              # 顯示活躍I/O進程
pidstat -d 1          # 按進程統(tǒng)計I/O

重點觀察 DISK READ 和 DISK WRITE 列，定位占用高的進程。

檢查文件系統(tǒng)和磁盤空間

df -h                 # 確認磁盤空間是否耗盡
dmesg | grep -i error # 檢查磁盤錯誤日志

若磁盤空間不足或存在壞道，會導致I/O性能驟降。

分析文件訪問模式

大文件讀寫：若進程頻繁讀寫大文件（如日志、數(shù)據(jù)庫文件），需優(yōu)化文件切分或歸檔策略。

小文件頻繁操作：大量小文件讀寫（如Web靜態(tài)資源）需考慮合并或使用緩存（如Redis）。

磁盤健康：使用 smartctl 檢測磁盤健康：

smartctl -a /dev/sda

直接原因：sda/dm-0/dm-2 的I/O飽和，大量讀請求導致隊列積壓和延遲。

查看CPU使用情況

關鍵指標分析

CPU負載：

• 運行隊列（r列）：多次超過 50（如 r=88），遠超CPU核心數(shù)（10核），說明進程排隊嚴重。
• 等待I/O的進程（b列）：最高達 44，表明大量進程因I/O阻塞。
• CPU時間分配：
  • 用戶態(tài)（us）：較低（3%~15%），排除用戶進程直接占用CPU的可能。
  • 系統(tǒng)態(tài)（sy）：多次超過 70%（如 sy=74%），內(nèi)核處理I/O或鎖競爭導致。
  • I/O等待（wa）：最高達 56%，確認磁盤是瓶頸。

I/O活動：

• 塊設備讀（bi）：最高達 377,968 塊/秒（約 147.5 MB/s），遠超機械盤吞吐能力。
• 上下文切換（cs）：高達 28,553次/秒，頻繁進程切換加劇CPU壓力。

內(nèi)存：

• 空閑內(nèi)存（free）：波動大（最低 139 MB），但 cache 較高（約 800 MB~1 GB），系統(tǒng)利用緩存緩解I/O壓力。
• 無Swap使用（si/so=0）：內(nèi)存未耗盡，但緩存頻繁刷寫可能影響性能。

排查步驟

定位高I/O進程

iotop -o -P          # 查看實時I/O讀寫進程
pidstat -d 1         # 按進程統(tǒng)計I/O

示例關注：

• DISK READ 列高（如 MySQL、日志服務）。
• 進程狀態(tài)：若多為 D（不可中斷睡眠），表明等待磁盤I/O。

檢查磁盤健康

smartctl -a /dev/sda    # 檢查磁盤SMART狀態(tài)
dmesg | grep -i error   # 查看磁盤錯誤日志

若發(fā)現(xiàn)壞道或高延遲，需更換磁盤。

分析文件訪問

lsof -p <PID>         # 查看進程打開的文件
strace -p <PID> -e trace=file  # 跟蹤文件操作

確認是否為 大文件順序讀 或 小文件隨機讀，優(yōu)化訪問模式。

檢查內(nèi)存緩存

free -m               # 查看緩存和緩沖區(qū)使用
sar -r 1              # 監(jiān)控內(nèi)存壓力

若 cache 頻繁釋放，表明內(nèi)存不足，需優(yōu)化應用內(nèi)存或擴容。

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

根據(jù)提供的 free -h 輸出系統(tǒng)存在 內(nèi)存耗盡風險（總內(nèi)存 15G，已用 14G，可用僅 600MB），但未觸發(fā) Swap（Swap=0），以下是詳細分析和解決方案：

關鍵指標分析

內(nèi)存分布：

• 已用內(nèi)存（used）：14G，占比 93%，接近物理內(nèi)存上限。
• 可用內(nèi)存（available）：600MB，表明系統(tǒng)處于內(nèi)存緊張狀態(tài)，可能觸發(fā) OOM Killer。
• 緩存/緩沖區(qū)（buff/cache）：911MB，較低，說明系統(tǒng)未有效利用緩存緩解I/O壓力。

潛在風險：

• OOM Killer：若突發(fā)內(nèi)存需求，內(nèi)核會強制終止進程釋放內(nèi)存（參考 /var/log/messages 中的 Out of memory 日志）。
• 性能下降：頻繁內(nèi)存回收導致CPU占用升高（如 kswapd 進程活躍）。

定位高內(nèi)存進程

top -o %MEM             # 按內(nèi)存占用排序
ps aux --sort=-%mem | head -n 10  # 列出前10內(nèi)存消耗進程

重點關注：

• %MEM 列：持續(xù)高占比的進程（如 MySQL、Java 應用）。
• 進程狀態(tài)：若為 D（不可中斷睡眠）或 Z（僵尸進程），可能關聯(lián)資源泄漏。

檢查內(nèi)存泄漏

valgrind --leak-check=full -v [應用程序路徑]   # 檢測特定程序內(nèi)存泄漏
cat /proc/[PID]/status | grep VmRSS           # 監(jiān)控進程內(nèi)存增長趨勢

若進程內(nèi)存持續(xù)增長且無釋放，需重啟服務或修復代碼。

優(yōu)化建議

系統(tǒng)層調(diào)優(yōu)

I/O調(diào)度器：改為 deadline 或 noop（SSD適用）：

  echo deadline > /sys/block/sda/queue/scheduler

內(nèi)核參數(shù)：增大磁盤隊列深度：

  echo 1024 > /sys/block/sda/queue/nr_requests

負載高的原因

• I/O密集型負載：大量讀操作（bi高）導致磁盤飽和，進程因等待I/O堆積（b列高），引發(fā)高負載和系統(tǒng)態(tài)CPU占用。
• 可能的場景：數(shù)據(jù)庫全表掃描、日志文件未輪轉(zhuǎn)、文件系統(tǒng)元數(shù)據(jù)操作頻繁（如小文件讀寫）。
• 磁盤I/O飽和（高bi、wa）導致進程排隊（高b）和系統(tǒng)態(tài)CPU占用（高sy）。
• 物理內(nèi)存耗盡（15G 中已用 14G），主要嫌疑為 MySQL 配置不當或 應用內(nèi)存泄漏。

到此這篇關于Centos7負載異常過高的排查思路與解決方法(Load Average)的文章就介紹到這了,更多相關Centos7負載異常過高排查與解決內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論