1. 程式人生 > >系統性能統計(CPU佔用率,記憶體佔用率,系統平均負載)

系統性能統計(CPU佔用率,記憶體佔用率,系統平均負載)

1、獲取cpu佔用情況

[[email protected] utx86]# top -n 1 |grep Cpu
Cpu(s): 1.9%us, 1.3%sy, 0.0%ni, 95.9%id, 0.6%wa, 0.1%hi, 0.2%si, 0.0%st

解釋:1.9%us是使用者佔用cpu情況

1.3%sy,是系統佔用cpu情況


2、獲得記憶體佔用情況

[[email protected] utx86]# top -n 1 |grep Mem
Mem: 2066240k total, 1515784k used, 550456k free, 195336k buffers

3、系統平均負載

也許你在學習

Linux作業系統,會遇到很多問題,這裡為你講解Linux系統Load average負載的知識,你可能對於 Linux 的負載均值(load averages)已有了充分的瞭解。負載均值在 uptime 或者 top 命令中可以看到,它們可能會顯示成這個樣子:

  load average: 0.09, 0.05, 0.01

  很多人會這樣理解負載均值:三個數分別代表不同時間段的系統平均負載(一分鐘、五 分鐘、以及十五分鐘),它們的數字當然是越小越好。數字越高,說明伺服器的負載越 大,這也可能是伺服器出現某種問題的訊號。

  而事實不完全如此,是什麼因素構成了負載均值的大小,以及如何區分它們目前的狀況是 “好”還是“糟糕”?什麼時候應該注意哪些不正常的數值?

  回答這些問題之前,首先需要了解下這些數值背後的些知識。我們先用最簡單的例子說明, 一臺只配備一塊單核處理器的伺服器。

  行車過橋

  一隻單核的處理器可以形象得比喻成一條單車道。設想下,你現在需要收取這條道路的過橋 費 - 忙於處理那些將要過橋的車輛。你首先當然需要了解些資訊,例如車輛的載重、以及還有多少車輛正在等待過橋。如果前面沒有車輛在等待,那麼你可以告訴後面的司機通過。 如果車輛眾多,那麼需要告知他們可能需要稍等一會。

  因此,需要些特定的代號表示目前的車流情況,例如:

  0.00 表示目前橋面上沒有任何的車流。 實際上這種情況與 0.00 和 1.00 之間是相同的,總而言之很通暢,過往的車輛可以絲毫不用等待的通過。

  1.00 表示剛好是在這座橋的承受範圍內。 這種情況不算糟糕,只是車流會有些堵,不過這種情況可能會造成交通越來越慢。

  超過 1.00,那麼說明這座橋已經超出負荷,交通嚴重的擁堵。 那麼情況有多糟糕? 例如 2.00 的情況說明車流已經超出了橋所能承受的一倍,那麼將有多餘過橋一倍的車輛正在焦急的等待。3.00 的話情況就更不妙了,說明這座橋基本上已經快承受不了,還有超出橋負載兩倍多的車輛正在等待。

  上面的情況和處理器的負載情況非常相似。一輛汽車的過橋時間就好比是處理器處理某執行緒 的實際時間。Unix系統定義的程序執行時長為所有處理器核心的處理時間加上執行緒 在佇列中等待的時間。

  和收過橋費的管理員一樣,你當然希望你的汽車(操作)不會被焦急的等待。所以,理想狀態 下,都希望負載平均值小於 1.00 。當然不排除部分峰值會超過 1.00,但長此以往保持這 個狀態,就說明會有問題,這時候你應該會很焦急。

  “所以你說的理想負荷為 1.00 ?”

  嗯,這種情況其實並不完全正確。負荷 1.00 說明系統已經沒有剩餘的資源了。在實際情況中 ,有經驗的系統管理員都會將這條線劃在 0.70:

  “需要進行調查法則”: 如果長期你的系統負載在 0.70 上下,那麼你需要在事情變得更糟糕之前,花些時間瞭解其原因。

  “現在就要修復法則”:1.00 。 如果你的伺服器系統負載長期徘徊於 1.00,那麼就應該馬上解決這個問題。否則,你將半夜接到你上司的電話,這可不是件令人愉快的事情。

  “凌晨三點半鍛鍊身體法則”:5.00。 如果你的伺服器負載超過了 5.00 這個數字,那麼你將失去你的睡眠,還得在會議中說明這情況發生的原因,總之千萬不要讓它發生。

  那麼多個處理器呢?我的均值是 3.00,但是系統執行正常!

  哇喔,你有四個處理器的主機?那麼它的負載均值在 3.00 是很正常的。

  在多處理器系統中,負載均值是基於核心的數量決定的。以 100% 負載計算,1.00 表示單個處理器,而 2.00 則說明有兩個雙處理器,那麼 4.00 就說明主機具有四個處理器。

  回到我們上面有關車輛過橋的比喻。1.00 我說過是“一條單車道的道路”。那麼在單車道 1.00 情況中,說明這橋樑已經被車塞滿了。而在雙處理器系統中,這意味著多出了一倍的 負載,也就是說還有 50% 的剩餘系統資源 - 因為還有另外條車道可以通行。

  所以,單處理器已經在負載的情況下,雙處理器的負載滿額的情況是 2.00,它還有一倍的資源可以利用。

  多核與多處理器

  先脫離下主題,我們來討論下多核心處理器與多處理器的區別。從效能的角度上理解,一臺主 機擁有多核心的處理器與另臺擁有同樣數目的處理效能基本上可以認為是相差無幾。當然實際 情況會複雜得多,不同數量的快取、處理器的頻率等因素都可能造成效能的差異。

  但即便這些因素造成的實際效能稍有不同,其實系統還是以處理器的核心數量計算負載均值 。這使我們有了兩個新的法則:

  “有多少核心即為有多少負荷”法則: 在多核處理中,你的系統均值不應該高於處理器核心的總數量。

  “核心的核心”法則: 核心分佈在分別幾個單個物理處理中並不重要,其實兩顆四核的處理器 等於 四個雙核處理器 等於 八個單處理器。所以,它應該有八個處理器核心。

  審視我們自己

  讓我們再來看看 uptime 的輸出

  ~ $ uptime

  23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36

  這是個雙核處理器,從結果也說明有很多的空閒資源。實際情況是即便它的峰值會到 1.7,我也從來沒有考慮過它的負載問題。

  那麼,怎麼會有三個數字的確讓人困擾。我們知道,0.65、0.42、0.36 分別說明上一分鐘、最後五分鐘以及最後十五分鐘的系統負載均值。那麼這又帶來了一個問題:

  我們以哪個數字為準?一分鐘?五分鐘?還是十五分鐘?

  其實對於這些數字我們已經談論了很多,我認為你應該著眼於五分鐘或者十五分鐘的平均數 值。坦白講,如果前一分鐘的負載情況是 1.00,那麼仍可以說明認定伺服器情況還是正常的。 但是如果十五分鐘的數值仍然保持在 1.00,那麼就值得注意了(根據我的經驗,這時候你應該增加的處理器數量了)。

  那麼我如何得知我的系統裝備了多少核心的處理器?

  在Linux 下,可以使用

  cat /proc/cpuinfo

  獲取你係統上的每個處理器的資訊。如果你只想得到數字,那麼就使用下面的命令:

  grep 'model name' /proc/cpuinfo | wc -l

  Popularity: 11% [?]

相關推薦

系統性統計CPU用率記憶體用率系統平均負載

1、獲取cpu佔用情況[[email protected] utx86]# top -n 1 |grep CpuCpu(s): 1.9%us, 1.3%sy, 0.0%ni, 95.9%id, 0.6%wa, 0.1%hi, 0.2%si, 0.0%st解釋:1.

APP性測試CPU

取數 ret lld __name__ split nes and return gen 獲取數據 :adb shell dumpsys cpuinfo | grep packagename result = os.popen("adb shell dumpsys cpu

操作系統性監控之CPU監控

com 2.0 lin pin pid 3.1 from ava 網絡io 操作系統性能監控 服務端程序除了應用本身性能外,依賴與服務器本身的性能,今天學習了如何監測服務器性能。包括:CPU、內存、網絡IO和磁盤使用率。 今天先看看如何監測CPU。 CPU監控 CPU使用

java獲取JVM的CPU用率記憶體用率、執行緒數及伺服器的網口吞吐率、磁碟讀寫速率

怎麼說呢,本人菜鳥一枚,費了幾天時間,終於做了一個用java獲取JVM的CPU佔用率、記憶體佔用率、執行緒數及伺服器的網口吞吐率、磁碟讀寫速率的實現。 其中windows環境下獲取jvm 的cpu佔用率這裡是參考網上別人的東西(在此感謝提供參考的網友),其他的都是基於自己的想法做出來的。該工具類

android系統性優化63---Android APP 卡頓問題分析及解決方案

使用者對卡頓的感知, 主要來源於介面的重新整理. 而介面的效能主要是依賴於裝置的UI渲染效能. 如果我們的UI設計過於複雜, 或是實現不夠友好,計算繪製演算法不夠優化, 裝置又不給力, 介面就會像卡住了一樣, 給使用者卡頓的感覺.如果你的應用介面出現卡頓不流暢的情況,不用懷疑,這很大原因是你沒有在16ms完成

Android 系統性優化11---UC效能優化方案

       一、效能優化六項指標:              效能、記憶體、穩定性、流量、電量、安裝包大小;       二、背景 ---- Android程式卡頓產生原因:              1、Android系統低效              --渲染執行緒、同步介面、廣播機制         

Android 系統性優化36---顯示效能指標

    從 Android 誕生的那一刻起,流暢度就為眾人所關注。一時之間,似乎所有人都在討論 Android 和 iOS 誰的流暢度更好。但是,毫不誇張的說,流暢度絕對是 Android 眾多效能維度中最為奇葩的一個。因為,為了刻畫這一效能維度,業界設計了各式各樣的指標來對

Android 系統性優化16--Android 系統性優化第4季

1)Cachematters for networking想要使得Android系統上的網路訪問操作更加的高效就必須做好網路資料的快取。這是提高網路訪問效能最基礎的步驟之一。從手機的快取中直接讀取資料肯定比從網路上獲取資料要更加的便捷高效,特別是對於那些會被頻繁訪問到的資料,

Android 系統性優化52---移動端效能監控方案Hertz

效能問題是造成App使用者流失的罪魁禍首之一。App的效能問題包括崩潰、網路請求錯誤或超時、響應速度慢、列表滾動卡頓、流量大、耗電等等。而導致App效能低下的原因有很多,除去裝置硬體和軟體的外部因素,其中大部分是開發者錯誤地使用執行緒、鎖、系統函式、程式設計正規化、資料結構等導致的。即便是最有經驗的程式設計師

Android 系統性優化34---Android UI 效能優化

Android官網 Slow rendering;個人覺得非常有價值,比如指出 物件分配、垃圾回收(GC)、執行緒排程以及Binder呼叫 是Android系統中常見的卡頓原因,更重要的是給出了定位和解決這些問題的方案;而非簡單地告訴你避免物件分配,減少佈局層級,減少過度

Android系統性優化64---build.設定

1. 強制把Home程式駐入記憶體.引數:ro.HOME_APP_ADJ=12.提高 JPG 質量為 100%引數:ro.media.enc.jpeg.quality=1003. VM 虛擬堆大小; 提高 RAM引數:dalvik.vm.heapsize=48m4. 使用 GPU 渲染UI引數:debug.s

Android 系統性優化28---Android 效能優化工具集合

磁碟檔案讀寫:每次開啟、關閉或者讀寫檔案,作業系統都需要經過從使用者態轉換為核心態的切換,這種狀態的切換本身是很消耗效能的,所以為了提高檔案的讀寫效率,就需要儘量減少使用者態和核心態的切換。使用快取可以避免重複讀寫,對於需要多次訪問的資料,在第一次取出資料的時候,將資料放在快

Android系統性優化44---全面&詳細的記憶體優化指南

前言在 Android開發中,效能優化策略十分重要本文主要講解效能優化中的記憶體優化,希望你們會喜歡目錄1. 定義優化處理 應用程式的記憶體使用、空間佔用2. 作用避免因不正確使用記憶體 & 缺乏管理,從而出現 記憶體洩露(ML)、記憶體溢位(OOM)、記憶體空間佔用

Android 系統性優化30---Android效能全面分析與優化方案研究

5.1、渲染問題先來看看造成應用UI卡頓的常見原因都有哪些?1、人為在UI執行緒中做輕微耗時操作,導致UI執行緒卡頓;2、佈局Layout過於複雜,無法在16ms內完成渲染;3、同一時間動畫執行的次數過多,導致CPU或GPU負載過重;4、View過度繪製,導致某些畫素在同一幀時間內被繪製多次,從而使CPU或G

python功能模組之psutil------ Linux效能CPU、磁碟、記憶體、網絡卡監控

採集系統的基本效能資訊包括CPU、記憶體、磁碟、網路等,可以完整描述當前系統的執行狀態及質量。psutil模組已經封裝了這些方法,使用者可以根據自身的應用場景,呼叫相應的方法來滿足需求,非常簡單實用。 (1)CPU資訊 Linux作業系統的CPU利用率有以下幾個部分:

C#獲取電腦硬體資訊CPU ID、主機板ID、硬碟ID、BIOS編號

最近學習過程中,想到提取系統硬體資訊做一些驗證,故而對網上提到的利用.NET System.Management類獲取硬體資訊做了進一步的學習、驗證。驗證是分別在4臺電腦,XP SP3系統中進行,特將驗證過程記錄於此。    說明:電腦1(聯想品牌電腦);電腦2(HP品牌電腦

C#獲取電腦硬體資訊CPU ID、主機板ID、硬碟ID、BIOS編號說明

最近學習過程中,想到提取系統硬體資訊做一些驗證,故而對網上提到的利用.NET System.Management類獲取硬體資訊做了進一步的學習、驗證。驗證是分別在4臺電腦,XP SP3系統中進行,特將驗證過程記錄於此。     說明: 電腦1(聯想品牌電腦); 電腦2(HP品

『開發技術』Ubuntu與Windows如何檢視CPU&GPU&記憶體用量

0 序·簡介   在使用Ubuntu或者Windows執行一些複雜資料運算時,需要關注下CPU、GPU以及記憶體佔用量,如果資料運算超出了負荷,會產生難以預測的錯誤。本文將演示如何用簡單地方式,實時監控Ubuntu或者Windows的CPU、GPU以及記憶體佔用量,教會大家如何實時

行內函數巨集定義記憶體對齊型別轉換

巨集 與 inline的區別 存在的價值,兩者都是文字替換,降低程式跳轉次數,提高效率 1. define 是預處理命令,無法除錯 ,最簡單文字替換,     inline 是編譯期替換,可以除錯, 存在引數型別檢查 2. 使用inline的時候,函式必須定義   直接定義的函式

網宿面試——有10T的IP地址資料記憶體只有10M怎麼找出出現頻率最大的那個IP

這種大資料的的題肯定是要分堆來做,再從堆中選出每個堆中最大的數,然後進行比較。1,首先就是如何進行分堆的問題,這邊我們使用hash來分成n個10M的小檔案,10T除以10M約等於1000000,所以使用hash(IP)%1000000,來分堆。2,從每個堆中選取出現次數最多的