資訊專欄INFORMATION COLUMN
隨著X86服務(wù)器的普及，目前各種主流數(shù)據(jù)庫(kù)、中間件、容器等都在逐步遷往Linux平臺(tái)，那對(duì)于應(yīng)用開發(fā)人員還有系統(tǒng)運(yùn)維人員掌握Linux相關(guān)技術(shù)將顯得尤為重要。
大家都知道服務(wù)器硬件簡(jiǎn)單理解就是Cpu+內(nèi)存+硬盤(存儲(chǔ))這些,那Linux就是負(fù)責(zé)調(diào)度這些硬件的軟件，讓大家一起和諧工作產(chǎn)生GDP。由此我們可以發(fā)現(xiàn)Linux主要就是管Cpu、內(nèi)存、硬盤這3類的工作，那換一個(gè)角度也就是說Linux運(yùn)行異常也大概率就這3類問題。
一說cpu，熟悉linux的都知道vmstat、top之類的命令，這里我們找個(gè)案例來解讀一下:
圖中可以看到這是一臺(tái)4cpu的服務(wù)器，目前procs-r17,18左右，cpuid空閑為0，由于這是一臺(tái)4cpu的服務(wù)器，理論上在某一時(shí)刻CPU的并行處理能力上限將是4，那procs-r遠(yuǎn)遠(yuǎn)大于cpu核心數(shù)意味著CPU忙不過來了，拼了命淦但還是有一堆任務(wù)等著它淦(來者不拒)，所以后面的cpuidle是0，那這就是一個(gè)高并發(fā)場(chǎng)景的cpu過載的特征。
通過top命令同樣可以看到目前有17個(gè)進(jìn)程處于running狀態(tài)，31.4%us:用戶狀態(tài)的調(diào)用,68.4%sy:涉及到系統(tǒng)內(nèi)核的調(diào)用.在進(jìn)程模塊中可以看到大量的dd進(jìn)程以及外層的bash(測(cè)試啟動(dòng)的ddif=/dev/zeroof=/dev/null命令)。當(dāng)發(fā)現(xiàn)服務(wù)器cpu過載時(shí)便可以通過這個(gè)思路來排查是否存在異常高消耗進(jìn)程。
注意對(duì)于多線程的程序比如java，%CPU字段很可能出現(xiàn)1100%這種情況，簡(jiǎn)單理解就是多個(gè)線程在cpu上運(yùn)行，相當(dāng)于消耗了11顆cpu的運(yùn)算量。
Procs
r: The number of processes waiting for run time.
再來說說內(nèi)存，由于內(nèi)存容量存在上限，比如服務(wù)器物理內(nèi)存128G，當(dāng)我們進(jìn)行一個(gè)500G數(shù)據(jù)運(yùn)算時(shí)，內(nèi)存是明顯放不下的，這時(shí)候Linux就引入了一個(gè)叫swap的東西，相當(dāng)于一個(gè)臨時(shí)空間，它基于磁盤，當(dāng)內(nèi)存不夠時(shí)，將部分當(dāng)前不使用的數(shù)據(jù)轉(zhuǎn)儲(chǔ)到swap空間中，這樣就可以最大化的利用有限的內(nèi)存進(jìn)行計(jì)算。
這個(gè)設(shè)計(jì)理念是好的，但實(shí)際生產(chǎn)環(huán)境中往往引發(fā)各種慘痛的案例,如下：
可以看到圖中的服務(wù)器總共配置了32Gswap空間,當(dāng)前已經(jīng)使用了12G說明已經(jīng)有數(shù)據(jù)被從內(nèi)存中swapout到臨時(shí)空間,top進(jìn)程也同樣出現(xiàn)kswapd[0-9],這些進(jìn)程就是專門負(fù)責(zé)swapin,swap out，Top中看到這類進(jìn)程時(shí)需額外注意。
這時(shí)cpu6.%us,12.6%sy,13.9%id,66.7%wa,這個(gè)wa說明存在磁盤IO等待,那簡(jiǎn)單理解就是由于swap空間的硬盤性能不足，內(nèi)存中的數(shù)據(jù)swapout速度過慢，引發(fā)系統(tǒng)層的panic，服務(wù)器hang,造成業(yè)務(wù)中斷故障。實(shí)際在這個(gè)案例過程中vmstat命令輸出也可以發(fā)現(xiàn)cpu–b/si so這些指標(biāo)的異常。
總結(jié)一下swap,一般在服務(wù)器系統(tǒng)安裝時(shí)系統(tǒng)管理員便會(huì)用本地盤劃分swap分區(qū)，這里本地盤的性能比較容易出現(xiàn)瓶頸,大量的swap易引發(fā)系統(tǒng)panic，另外一個(gè)Linux使用vm.swappiness參數(shù)來控制使用物理內(nèi)存還是使用交換空間的權(quán)重,在老舊一些的版本中設(shè)置為0容易引發(fā)系統(tǒng)bug推薦設(shè)置為1，在較新的版本中比如redhat7/8則推薦設(shè)置為0來避免使用交換空間，那在一些數(shù)據(jù)庫(kù)一體機(jī)等專有服務(wù)器上物理內(nèi)存都能達(dá)到TB級(jí)，這種也可以直接關(guān)閉swap功能。
參考Man :
Man vmstat
Procs
r: The number of processes waiting for run time.
man top
2c. SUMMARY Area Fields
us = user mode
sy = system mode
ni = low priority user mode (nice)
id = idle task
wa = I/O waiting
man vmstat ，
Swap
si: Amount of memory swapped in from disk (/s).
最后我們?cè)趤碚f說磁盤類的問題，目前主流方法都是基于磁盤響應(yīng)時(shí)間作為判斷依據(jù)(iostat命令輸出的await值)，這里不區(qū)分讀寫，比如SSD存儲(chǔ)響應(yīng)時(shí)間都在5ms以內(nèi)，高端SSD的響應(yīng)時(shí)間甚至達(dá)到1ms以內(nèi),而傳統(tǒng)的機(jī)械硬盤響應(yīng)時(shí)間則較慢一些，高端類的存儲(chǔ)陣列也在20ms以內(nèi)，差一點(diǎn)的40ms，50ms也比較常見。
了解了這些當(dāng)我們通過iostat命令來核查服務(wù)器磁盤響應(yīng)情況時(shí)便能夠直觀的發(fā)現(xiàn)是否存在問題。如圖：
可以看到%iowait已經(jīng)超過了%user,%system,IO方面壓力較大，再往下可以看到sdb/sdc讀寫都非常少而await(響應(yīng)時(shí)間單位ms)值卻異常的大，IO幾乎無法完成,推測(cè)存儲(chǔ)出現(xiàn)異常，通知系統(tǒng)管理員核驗(yàn)確認(rèn)RAID出現(xiàn)降級(jí)故障.這里需要額外注意iostat輸出的sdb/sdc的%util值為100%，這個(gè)%util100實(shí)際沒有參考意義，因?yàn)橄到y(tǒng)也并不知道后端存儲(chǔ)的iops能力以及使用率，只有await才能判斷磁盤IO響應(yīng)是否正常.如圖：
這是一臺(tái)本地機(jī)械盤(sda),在少量的讀寫情況下%util已經(jīng)97.9,但響應(yīng)時(shí)間24.18任然在正常范圍內(nèi)，不能根據(jù)util%值來判斷sda是否存在問題。而下面的sdb/sdc等等磁盤都是外掛SSD存儲(chǔ)，可以看到iops近萬的情況下較慢的盤await也才1點(diǎn)幾ms，快的盤都不到1ms。
await
通過以上三板斧，我們便可以對(duì)當(dāng)前Linux系統(tǒng)的運(yùn)行情況做到心中有數(shù)，在此基礎(chǔ)上實(shí)際運(yùn)用過程中,比如swap引起的案例中,vmstatcpu-b/si so以及iostat的swap空間掛載盤一定會(huì)有所表現(xiàn)，不能教條的認(rèn)為一定是這一方面的問題,所以需要結(jié)合起來分析。
文章首發(fā)于2021年02月25日
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/129277.html
摘要：函數(shù)名列出某個(gè)函數(shù)的源代碼，含函數(shù)名上下各五行類比調(diào)試或從開始連續(xù)而非單步執(zhí)行程序遇到斷點(diǎn)停下。相當(dāng)于中的或單條執(zhí)行。 目錄 一、調(diào)試器gdb 1、可以使用gdb的可執(zhí)行文件生成 2、使用命令 1、開始調(diào)試和退出調(diào)試 2、list 3、類比vs調(diào)試 4、代碼調(diào)試三劍客 5、變量 6、斷點(diǎn) 二...
摘要：環(huán)境基礎(chǔ)開發(fā)工具使用軟件包管理器的三板斧查看軟件包安裝軟件卸載軟件和互傳文件的三種模式的轉(zhuǎn)換命令模式插入模式底行模式編譯器使用函數(shù)庫(kù)調(diào)試器使用項(xiàng)目自動(dòng)化構(gòu)建工具軟件包管理器軟件包和軟件包管理器就好比手機(jī)上的和應(yīng)用 ...
摘要：溝通方面的技巧，后端，產(chǎn)品，設(shè)計(jì)，測(cè)試等領(lǐng)域的知識(shí)?？梢钥闯觯岸诵枰鷪F(tuán)隊(duì)中的各種角色交流對(duì)接，對(duì)相關(guān)的領(lǐng)域有了解可以降低溝通的成本。 前端除了JS,HTML,CSS三板斧，還要懂些什么？有什么東西對(duì)我們提升自己前端水平有幫助？ 開發(fā)的過程 我們不如先了解一下前端開發(fā)的過程 跟產(chǎn)品了解需求 跟后臺(tái)溝通接口 跟美術(shù)對(duì)接設(shè)計(jì) 寫文檔 編寫代碼 使用babel，sass等工具編譯代碼 部...
摘要：如果發(fā)現(xiàn)某類對(duì)象占用內(nèi)存很大例如幾個(gè)，很可能是類對(duì)象創(chuàng)建太多，且一直未釋放。 OOM(OutOfMemoryError) 問題歸根結(jié)底三點(diǎn)原因： 本身資源不夠 申請(qǐng)的內(nèi)存太多 資源耗盡 解決思路，換成Java服務(wù)分析，三個(gè)原因也可以解讀為： 有可能是內(nèi)存分配確實(shí)過小，而正常業(yè)務(wù)使用了大量?jī)?nèi)存 某一個(gè)對(duì)象被頻繁申請(qǐng)，卻沒有釋放，內(nèi)存不斷泄漏，導(dǎo)致內(nèi)存耗盡 某一個(gè)資源被頻繁申請(qǐng)，系統(tǒng)...
摘要：前言是現(xiàn)在幾乎每個(gè)項(xiàng)目中必備的一個(gè)東西，但是其工作原理避不開對(duì)的解析在生成的過程，有引擎，早期了項(xiàng)目，了解這個(gè)之前我們先來看看這種引擎解析出來是什么東西。 前言 babel是現(xiàn)在幾乎每個(gè)項(xiàng)目中必備的一個(gè)東西，但是其工作原理避不開對(duì)js的解析在生成的過程，babel有引擎babylon，早期fork了項(xiàng)目acron，了解這個(gè)之前我們先來看看這種引擎解析出來是什么東西。不光是babel還有...
閱讀 1347·2023-01-11 13:20
閱讀 1686·2023-01-11 13:20
閱讀 1133·2023-01-11 13:20
閱讀 1861·2023-01-11 13:20
閱讀 4104·2023-01-11 13:20
閱讀 2706·2023-01-11 13:20
閱讀 1386·2023-01-11 13:20
閱讀 3599·2023-01-11 13:20
