監控系統元件
監控系統元件
在進行效能監控時,應該監控系統的四個基本元件:
l 處理器檢查其利用率及達到了什麼樣的峰值。
l 記憶體檢查記憶體被佔用量,及其可用量。
l 磁碟檢查磁碟空間可用量,磁碟空間是如何被佔用的,還有哪些需求需要佔用磁碟空間,還需要了解磁碟讀取速度(響應時間)。
l 網路檢查網路通訊的吞吐量、延遲和錯誤率。
處理器
監控CPU 以確保系統不存在失控程式,並確保CPU 週期在各執行程式中平均分配。要做到這一點,方法之一是呼叫正在執行的程式列表,然後確定每個程式所佔CPU 的百分比。另外一個方法是檢測系統程式的平均負載。大多數作業系統提供了CPU 效能的多種檢視。程式是指在L.inux 或UNIX 作業系統上執行的一個工作單元。一個程式可能同時執行一個或多個程式。多執行緒應用程式,如MySQL,通常以多程式的形式出現在作業系統中。
當CPU 處在高效能負載下且爭用激烈時,系統將執行緩慢,甚至出現當機情況。在這種情況下必須減少程式的數量或者減少那些消耗較多CPU 時間的程式的CPU 使用率。然而一定要監控CPU,並確認系統問題確實是由CPU 的高使用率導致的——系統執行緩慢更有可能是記憶體爭用導致的,下一節將討論這個問題。
CPU 超載的一些常見的解決方法是:
提供新伺服器執行程式這當然是最好的辦法,但是新伺服器需要資金。有經驗的系統管理員通常可以找到其他的方法去減少CPU 的使用率,尤其是當組織更願意花時間而不是花錢在這件事情上時。
刪除不必要的程式大量系統的後臺執行程式可能在某些場合有用,但大多數時候會使系統陷入癱瘓。然而,作為一個系統管理員,必須非常瞭解作業系統,以確定哪些程式是不必要的。
殺死失控的程式當效能問題間歇地或偶爾出現時,可能是由有缺陷的應用程式導致的,這些失控的程式往往是罪魁禍首。倘若你使用可控的或有序的方法不能夠停止失控的程式,可能需要使用強制退出對話方塊或使用命令列強制性地終止這個程式。
最佳化應用程式有些應用程式時常會佔用超過其實際需要的CPU 時間或其他資源。設計糟糕的SQL語句經常拖累了資料庫系統。
較低的程式優先順序有些程式可以在後臺作業執行,例如報表生成器,而且它們可以執行得更慢,以給互動程式騰出空間。
重新安排程式也許有些報表生成程式可以在系統負荷較低的夜間執行。
佔用太多CPU 時間的程式被稱為CPU-bound 或processor-bound,這意味著它們不會為等待I/O 暫停自己,也不能被交換出記憶體。
如果你發現CPU 沒有被爭用,此時僅有少數幾個程式在執行或者不存在消耗大量CPU時間的程式,那麼此時很可能是其他地方導致效能問題的發生:如等待磁碟I/O、記憶體不足、過度頁交換等。
記憶體
監控記憶體是為了確保應用程式不要請求過多的記憶體,因為請求過多的記憶體會浪費系統管理記憶體的時間。作業系統從最初使用有限的隨機存取儲存器(RAM 或主記憶體),已經發展到使用磁碟儲存器來儲存未使用的部分或主記憶體頁面,這種技術被稱為分頁或交換,可以儲存懸停程式的記憶體,並在程式被啟用時將被儲存的記憶體恢復出來,這樣系統在同一時間內比主記憶體系統負擔的程式更多。雖然記憶體塊在記憶體與磁碟間交換的代價相對較高(與直接訪問主記憶體相比,比較耗時),但是現代作業系統在這方面能夠做到很快,那麼這種缺陷就不是問題了,除非它無法使處理器和磁碟的執行速度跟上需求。
然而作業系統可能定期回收較高水平的交換記憶體。一定要測量一段時間內的記憶體使用率,確保不存在常規清除操作。
在高分頁期,記憶體不足有可能是因為失控程式佔用太多的記憶體或者系統執行了過多的程式以至於佔用過多的記憶體。這種高分頁被稱為thrashing,與CPU 資源爭用類似。消耗過多記憶體的程式被稱為memory-bound。
在處理記憶體效能問題時,自然想到的處理方法是增加更多的記憶體。雖然這樣可以解決問題,但記憶體也有可能在各子系統間分配不均勻。
在這種情況下你有幾件事情可以做,可以分配不同數量的記憶體給系統的元件(如核心或檔案系統),或者分配不同數量的記憶體給允許進行記憶體調整的各種應用程式(如MySQL),還可以更改子系統的分頁優先順序,這樣可以使作業系統更早開始分頁。
調整伺服器記憶體子系統時要小心,請務必參考關於提高特定作業系統效能的文件或書籍。
如果在監控記憶體時發現系統的分頁並不頻繁,而系統效能仍存在問題,此時,效能問題可能跟其他的子系統有關。
磁碟
監控磁碟使用率是為了確保系統擁有足夠的可用磁碟空間且擁有足夠的I/O 頻寬,以使程式執行時不會出現明顯的延時。可以使用per-process 或overall transfer 讀取磁碟的傳輸速率來衡量以上情況。per-process 傳輸速率是指單個程式可以讀寫的資料量。overalltransfer 傳輸速率是指讀寫磁碟資料的最大頻寬。一些有多個磁碟控制器的系統可能單獨衡量每個磁碟控制器的overall transfer 傳輸速率。
如果有一個或更多的程式消耗過多的最大磁碟傳輸率,將會出現效能問題。這就像程式消耗太多的CPU 週期一樣,同樣會對系統的其餘程式產生不利的影響:它將“餓死”其他程式,迫使它們等待更長的磁碟訪問時間。
消耗太多磁碟傳輸率的程式被稱為disk-bound,也就是說它訪問磁碟的頻率大於磁碟傳輸率能夠提供的份額。如果能夠減少disk-bound 程式給I/O 系統帶來的壓力,將會為其他程式騰出更多的頻寬。
一種滿足執行大量的磁碟I/O 的程式需要的方法是增加檔案系統的塊大小,從而使大型傳輸更有效,這樣還可減少由disk-bound 程式帶來的系統開銷。然而,這可能會使其他程式執行得更慢。
當在只有一個控制器或磁碟的伺服器上最佳化檔案系統時需要謹慎行事。請務必參考提高具體作業系統效能的文件或書籍。
如果資源充足,那麼可以新增新的磁碟控制器和磁碟陣列來處理磁碟爭用,將其中一個disk-bound 程式的相關資料移到新的磁碟控制器上。另一種處理磁碟爭的方法是將diskbound程式移到另外一個使用率較低的伺服器上。最後一種方法是在某些情況下,透過升級磁碟系統來使系統執行更快,從而增加磁碟的頻寬。
至於先從哪裡開始最佳化或者哪種最佳化方法是最好的,有不同觀點。但是我們認為:
如果需要執行大量的程式,就需要擴大磁碟傳輸速率或將程式分佈在不同的磁碟整列或系統上。
如果需要執行少數幾個資料訪問量大的程式,就需要透過增加檔案系統的塊大小來增加單個程式的傳輸速率。
可能需要在這兩個解決方案之間取得平衡,透過將有些程式移到其他系統上的方法來滿足獨特的混合程式(mix of processes)。
網路子系統
監控網路介面以確保系統擁有足夠的頻寬,並確保正在傳送或接收的資料具有高質量。
有些程式試圖讀寫的資料超過網路配置或硬體所允許的範圍,以至於它們消耗了過多的網路頻寬,這樣的程式被稱為network-bound。這類程式為了避免自己發生延時而阻止其他程式訪問充足的網路頻寬。
網路頻寬問題通常表現為完全佔用網路介面的最大頻寬,可以透過給不同程式分配特定網路埠的方式來解決這個問題。
網路資料質量問題通常表現為在網路介面上遭遇大量錯誤。幸運的是,作業系統和資料傳輸應用程式通常採用checksumming 或其他一些演算法來檢測這類錯誤,但是重發將給網路和作業系統帶來沉重負擔。解決這個問題可能需要將一些應用程式移到同一網路的其他系統上,或者可能需要安裝額外的網路卡,而且在改變網路硬體、重新配置網路協議或者將系統移動到網路中不同的子網後,通常需要進行診斷分析。
當提起程式時你可能聽到I/O-bound 或I/O-starved 這樣的術語。這通常是指程式佔用太多的磁碟或網路頻寬。
本文節選自《高可用MySQL:構建健壯的資料中心 》一書
圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-708303
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/13164110/viewspace-708848/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 實時監控系統,統一監控企業APIAPI
- 智慧影片監控系統
- Linux 系統監控指南Linux
- 智慧工地監控系統
- Mac系統監控工具Mac
- 打造前端監控系統前端
- 手刃前端監控系統前端
- python搭建系統監控Python
- 惠普監控元件被爆LPE,可使用系統許可權元件
- 系統監控&JVM監控指標資料查詢JVM指標
- 影片監控ai分析系統AI
- 影片監控智慧分析系統
- 電力影片監控系統
- 直播間截留監控系統
- Prometheus監控報警系統Prometheus
- 前端監控系統Sentry搭建前端
- Go 系統監控利器-gopsutilGo
- linux系統 物理硬碟監控Linux硬碟
- Docker 容器監控系統初探Docker
- sysstat——系統效能監控神器
- 前端監控基礎篇 — Docker + Sentry 搭建前端監控系統前端Docker
- 一種對雲主機進行效能監控的監控系統及其監控方法
- 煤礦ai智慧監控系統AI
- 工地ai智慧影片監控系統AI
- 監控影片行為分析系統
- 煤礦影片監控分析系統
- 秸稈焚燒監控系統
- 明廚亮灶監控系統
- 智慧工地裝置監控系統
- 施工現場影片監控系統
- 智慧校園影片監控系統
- 系統監控工具:MenuBar Stats for macMac
- 部署Sentry日誌監控系統
- 監控系統告警指令碼集合指令碼
- 駕駛員監控系統(DMS)
- 搭建前端錯誤監控系統前端
- Kafka監控系統Kafka Eagle剖析Kafka
- 雪亮工程視訊監控系統建設方案重點人員監控系統開發
- 【系統設計】指標監控和告警系統指標