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