1. 程式人生 > >kswapd程序cpu使用高導致宕機

kswapd程序cpu使用高導致宕機

ubuntu核心更新到4.4.0-51之後,系統莫名出現宕機,不定時的有kswapd程序佔用CPU,原因如下

physical mem 不足,引起 swap 頻繁讀寫。

kswapd0 是系統的虛擬記憶體管理程式,如果實體記憶體不夠用,系統就會喚醒 kswapd0 程序,由 kswapd0 分配磁碟交換空間作快取,因而佔用大量的 CPU 資源。

檢視記憶體及swap使用率:發現還有空餘的記憶體,但是已經開始用swap了。

記憶體使用到多少開始使用swap?

vm.swappiness   這個核心引數控制
/proc/sys/vm/swappiness

這個交換引數控制核心從實體記憶體移出程序,移到交換空間。該引數從0到100,當該引數=0,表示只要有可能就盡力避免交換程序移出實體記憶體;該引數=100,這告訴核心瘋狂的將資料移出實體記憶體移到swap快取中。

The defaultvalue I’ve seen on both enterprise level Red Hat and SLES servers is 60.
To find out what the default value is on aparticular server, run:
sysctl vm.swappiness
The value is also located in/proc/sys/vm/swappiness.

PS:設定vm.swappiness=0 後並不代表禁用swap分割槽,只是告訴核心,能少用到swap分割槽就儘量少用到,設定vm.swappiness=100的話,則表示儘量使用swap分割槽,預設的值是60

調整記憶體引數,當記憶體使用率不足10%(開始是預設值60)時在使用swap,儘量避免使用swap,減少喚醒軟中斷程序,從而降低ksoftirqd程序對cpu的佔用。

vm.swappiness=0

關於linux記憶體分配機制

在linux的記憶體分配機制中,優先使用實體記憶體,當實體記憶體還有空閒時(還夠用),不會釋放其佔用記憶體,就算佔用記憶體的程式已經被關閉了,該程式所佔用的記憶體用來做快取使用,對於開啟過的程式、或是讀取剛存取過得資料會比較快。

一.  我們先來檢視一個記憶體使用的例子:
[[email protected] ~]$ free -m
total       used      free     shared    buffers    cached
Mem:       72433     67075     5357      0       558       62221
-/+ buffers/cache:    4295      68138
Swap:       72096      91      72004
上述結果顯示了67075M的used,但是(-/+ buffers/cache)減去buffers和cache的結果可以看到,所以當前程序實際佔用記憶體是4296M。
可以這麼理解:在linux的記憶體分配機制中,優先使用實體記憶體,當實體記憶體還有空閒時(還夠用),不會釋放其佔用記憶體,就算佔用記憶體的程式已經被關閉了,該程式所佔用的記憶體用來做快取使用,對於開啟過的程式、或是讀取剛存取過得資料會比較快。
如上面的例子:使用了72433M的記憶體,67075M被佔用,但是buuffer和cached部分作為快取,可以使用命中率的方式提高使用效率,而且這部分快取是根據指令隨時可以釋放的,我們可以認為這部分記憶體沒有實際被使用,也可以認為它是空閒的。
因此檢視目前程序正在實際被使用的記憶體,是used-(buffers+cache),也可以認為如果swap沒有大量使用,mem還是夠用的,只有mem被當前程序實際佔用完(沒有了buffers和cache),才會使用到swap的。

二. Swap配置對效能的影響
分配太多的Swap空間會浪費磁碟空間,而Swap空間太少,則系統會發生錯誤。如果系統的實體記憶體用光了,系統就會跑得很慢,但仍能執行;如果Swap空間用光了,那麼系統就會發生錯誤。例如,Web伺服器能根據不同的請求數量衍生出多個服務程序(或執行緒),如果Swap空間用完,則服務程序無法啟動,通常會出現“application is out of memory”的錯誤,嚴重時會造成服務程序的死鎖。因此Swap空間的分配是很重要的。
通常情況下,Swap空間應大於或等於實體記憶體的大小,最小不應小於64M,通常Swap空間的大小應是實體記憶體的2-2.5倍。但根據不同的應用,應有不同的配置:如果是小的桌面系統,則只需要較小的Swap空間,而大的伺服器系統則視情況不同需要不同大小的Swap空間。特別是資料庫伺服器和Web伺服器,隨著訪問量的增加,對Swap空間的要求也會增加,一般來說對於4G 以下的實體記憶體,配置2倍的swap,4G 以上配置1倍。
另外,Swap分割槽的數量對效能也有很大的影響。因為Swap交換的操作是磁碟IO的操作,如果有多個Swap交換區,Swap空間的分配會以輪流的方式操作於所有的Swap,這樣會大大均衡IO的負載,加快Swap交換的速度。如果只有一個交換區,所有的交換操作會使交換區變得很忙,使系統大多數時間處於等待狀態,效率很低。用效能監視工具就會發現,此時的CPU並不很忙,而系統卻慢。這說明,瓶頸在IO上,依靠提高CPU的速度是解決不了問題的。

三.  Linux 記憶體機制
Linux支援虛擬記憶體(VirtualMmemory),虛擬記憶體是指使用磁碟當作RAM的擴充套件,這樣可用的記憶體的大小就相應地增大了。核心會將暫時不用的記憶體塊的內容寫到硬碟上,這樣一來,這塊記憶體就可用於其它目的。當需要用到原始的內容時,它們被重新讀入記憶體。這些操作對使用者來說是完全透明的;Linux下執行的程式只是看到有大量的記憶體可供使用而並沒有注意到時不時它們的一部分是駐留在硬碟上的。當然,讀寫硬碟要比直接使用真實記憶體慢得多(要慢數千倍),所以程式就不會象一直在記憶體中執行的那樣快。用作虛擬記憶體的硬碟部分被稱為交換空間(Swap Space)。
一般,在交換空間中的頁面首先被換入記憶體;如果此時沒有足夠的實體記憶體來容納它們又將被交換出來(到其他的交換空間中)。如果沒有足夠的虛擬記憶體來容納所有這些頁面,Linux就會波動而不正常;但經過一段較長的時間Linux會恢復,但此時系統已不可用了。
有時,儘管有許多的空閒記憶體,仍然會有許多的交換空間正被使用。這種情況是有可能發生的,例如如果在某一時刻有進行交換的必要,但後來一個佔用很多實體記憶體的大程序結束並釋放記憶體時。被交換出的資料並不會自動地交換進記憶體,除非有這個需要時。此時實體記憶體會在一段時間內保持空閒狀態。對此並沒有什麼可擔心的,但是知道了是怎麼一回事,也就無所謂了。
許多作業系統使用了虛擬記憶體的方法。因為它們僅在執行時才需要交換空間,以解決不會在同一時間使用交換空間,因此,除了當前正在執行的作業系統的交換空間,其它的就是一種浪費。所以讓它們共享一個交換空間將會更有效率。
注意:如果會有幾個人同時使用這個系統,他們都將消耗記憶體。然而,如果兩個人同時執行一個程式,記憶體消耗的總量並不是翻倍,因為內碼表以及共享的庫只存在一份。

Linux系統常常動不動就使用交換空間,以保持儘可能多的空閒實體記憶體。即使並沒有什麼事情需要記憶體,Linux也會交換出暫時不用的記憶體頁面。這可以避免等待交換所需的時間:當磁碟閒著,就可以提前做好交換。可以將交換空間分散在幾個硬碟之上。針對相關磁碟的速度以及對磁碟的訪問模式,這樣做可以提高效能。

與訪問實體記憶體相比,磁碟的讀寫是很慢的。另外,在相應較短的時間內多次讀磁碟同樣的部分也是常有的事。例如,某人也許首先閱讀了一段E-mail訊息,然後為了答覆又將這段訊息讀入編輯器中,然後又在將這個訊息拷貝到資料夾中時,使得郵件程式又一次讀入它。或者考慮一下在一個有著許多使用者的系統中 ls命令會被使用多少次。通過將資訊從磁碟上僅讀入一次並將其存於記憶體中,除了第一次讀以外,可以加快所有其它讀的速度。這叫作磁碟緩衝(Disk Buffering),被用作此目的的記憶體稱為高速緩衝(Buffer Cache)。但是,由於記憶體是一種有限而又不充足的資源,高速緩衝不可能做的很大(它不可能包容要用到的所有資料)。當緩衝充滿了資料時,其中最長時間不用的資料將被捨棄以騰出記憶體空間用於新的資料。

對寫磁碟操作來說磁碟緩衝技術同樣有效。一方面,被寫入磁碟的資料常常會很快地又被讀出(例如,原始碼檔案被儲存到一個檔案中,又被編譯器讀入),所以將要被寫的資料放入緩衝中是個好主意。另一方面,通過將資料放入緩衝中,而不是將其立刻寫入磁碟,程式可以加快執行的速度。以後,寫的操作可以在後臺完成,而不會拖延程式的執行。
大多數作業系統都有高速緩衝(儘管可能稱呼不同),但是並不是都遵守上面的原理。有些是直接寫(Write-Through):資料將被立刻寫入磁碟(當然,資料也被放入快取中)。如果寫操作是在以後做的,那麼該快取被稱為後臺寫(Write-Back)。後臺寫比直接寫更有效,但也容易出錯:如果機器崩潰,或者突然掉電,緩衝中改變過的資料就被丟失了。如果仍未被寫入的資料含有重要的薄記資訊,這甚至可能意味著檔案系統(如果有的話)已不完整。
針對以上的原因,出現了很多的日誌檔案系統,資料在緩衝區修改後,同時會被檔案系統記錄修改資訊,這樣即使此時系統掉電,系統重啟後會首先從日誌記錄中恢復資料,保證資料不丟失。當然這些問題不再本文的敘述範圍。
由於上述原因,在使用適當的關閉過程之前,絕對不要關掉電源,Sync命令傾空(Flushes)緩衝,也即,強迫所有未被寫的資料寫入磁碟,可用以確定所有的寫操作都已完成。在傳統的UNIX系統中,有一個叫做update的程式運行於後臺,每隔30秒做一次sync操作,因此通常無需手工使用sync命令了。Linux另外有一個後臺程式,Bdflush,這個程式執行更頻繁的但不是全面的同步操作,以避免有時sync的大量磁碟I/O操作所帶來的磁碟的突然凍結。
在Linux中,Bdflush是由update啟動的。通常沒有理由來擔心此事,但如果由於某些原因bdflush程序死掉了,核心會對此作出警告,此時你就要手工地啟動它了(/sbin/update)。
快取(Cache)實際並不是緩衝檔案的,而是緩衝塊的,塊是磁碟I/O操作的最小單元(在Linux中,它們通常是1KB)。這樣,目錄、超級塊、其它檔案系統的薄記資料以及非檔案系統的磁碟資料都可以被緩衝了。緩衝的效力主要是由它的大小決定的。緩衝太小的話等於沒用。它只能容納一點資料,因此在被重用時,所有緩衝的資料都將被傾空。實際的大小依賴於資料讀寫的頻次、相同資料被訪問的頻率。只有用實驗的方法才能知道。
如果快取有固定的大小,那麼快取太大了也不好,因為這會使得空閒的記憶體太小而導致進行交換操作(這同樣是慢的)。為了最有效地使用實際記憶體,Linux自動地使用所有空閒的記憶體作為高速緩衝,當程式需要更多的記憶體時,它也會自動地減小緩衝的大小。
這就是一般情況下Linux記憶體的一般機制,真正的Linux記憶體的執行機制遠遠比這個複雜。


相關推薦

kswapd程序cpu使用導致

ubuntu核心更新到4.4.0-51之後,系統莫名出現宕機,不定時的有kswapd程序佔用CPU,原因如下 physical mem 不足,引起 swap 頻繁讀寫。 kswapd0 是系統的虛擬記憶體管理程式,如果實體記憶體不夠用,系統就會喚醒 kswapd0 程

記憶體佔用過,快取不釋放導致處理方案

故障現象: 1、某分行部署的某臺伺服器記憶體佔用過高,導致宕機; 2、程式碼層面檢查暫未發現問題,伺服器硬重啟持續一段時間後(3-5天)再次佔滿。 發現問題: 趕往現場後進行檢查,當時是一切正常的,今有DB2程序佔用18%,在正常範圍內; 在crontab 中發現有兩個指

emwin之錯誤使用控制元件函式導致現象

@2018-10-15 導致宕機的程式碼示例如下 1 /** 2 * @brief widget ID define 3 * @{ 4 */ 5 6 #define ID_WINDOW_0 (GUI_ID_USER + 0x00) 7

類system32\drivers\**mom.sys檔案損壞導致無法啟動Windows解決方法

類system32\drivers\**mom.sys檔案損壞導致宕機無法啟動Windows解決方法可利用第三方工具修改原系統登錄檔的方法來修復系統,即通過WinPE進入系統。1、  在protal介面將故障虛擬機器啟動方式修改為光碟機啟動(操作>>選項>&

Salesforce.com遭遇電力故障導致,恢復時丟失4小時資料

16歲的Salesforce.com剛剛(2016年5月12日)犯了一個不小的錯誤,太平洋標準時間 (PST)週二早上6:30到週三下午14:30,遭遇了一次由於停電導致的大範圍宕機,此次宕機影響了北美的14個站點,影響了灣區的大量使用者——灣區歷來被稱為Salesforce.com的後院,同時,部

STM32F030 中斷太頻繁導致

最近在忙一個專案,使用了STM32F030的微控制器,定時器用系統定時器,每10us中斷一次。在程式少的時候,沒有發現宕機情況,但是隨著功能的豐富,經常出現宕機問題,具體表現為while(1)迴圈無法

TIME_WAIT、NON_ESTABLISHED 連線數過導致tomcat服務直接

TCP常見配置參考地址: http://shift-alt-ctrl.iteye.com/blog/1966744;https://www.cnblogs.com/fczjuever/archive/2013/04/05/3000697.html 以上圖最大連線數接近了2000,這個對於單機環境來說基本已

goldengate源端意外,傳輸程序終止,導致OGG-01031報錯

伺服器宕機,沒有停止dpump程序,啟動後處於abend狀態,檢查ggserr.log報以下錯誤: 2011-04-01 11:13:19 ERROR OGG-01031 Oracle GoldenGate Capture for Oracle, dpump.prm: There is a proble

Mysql DBA 級運維學習筆記-一主多從從庫切換主繼續和從庫同步過程

復制 導入數據 之間 pro vim 庫服務器 chan mas 優點 1.主庫master 宕機 登錄從庫show processlist\G 看兩個線程的更新狀態 mysql> show processlist\G ************************

ORA-0402導致oracle11gADG備庫問題處理

ADG ORA-4021 發現數據庫告警,查看alert日誌,發現如下報錯Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_lgwr_26383.trc:ORA-04021: timeout occurred while

dubbo可用之zookeeper、Dubbo直連、負載均衡、服務降級、叢集容錯

之前我們說了dubbo超時重試啟動檢查等配置,接下來我們說一下dubbo高可用的一些配置 1. zookeeper宕機 我們接下來討論一下如果zookeeper宕機對我們的服務提供者消費者有什麼影響 現象:zookeeper註冊中心宕機,還可以消費dubbo暴露的服務。 原因

一個定時任務導致的業務頻繁事故

現象和背景: 最近,一個客戶的mongodb經常發生記憶體不足的情況,由於對業務也未產生太大影響,也沒有太多關注。然而近期業務發生頻繁宕機,尤其近日,發生宕機的概率越來越大,一天宕機次數達7、8次之多,雖然每次僅有一分鐘故障時間,但整體影響還是不小。 歷史處理方式: 通過對jav

【轉】Linux下java程序CPU佔用率分析方法

文章轉載的地址: https://blog.linuxeye.cn/343.html   在工作當中,肯定會遇到由程式碼所導致的高CPU耗用以及記憶體溢位的情況。這種情況發生時,我們怎麼去找出原因並解決。 一般解決方法是通過top命令找出消耗資源高的執行緒id,利用strace命令檢視該執行緒

Oracle RAC一節點導致另一節點HANG的問題分析

        正所謂“福無雙至,禍不單行”,生產上有套2節點Oracle 11.2.0.4資料庫,其中2節點因硬體故障宕機,1節點去HANG住了。我們一起來分析這起故障。     &

關於F28335的XINTF模組導致上電的問題

參考論壇 關於F28335的XINTF模組導致上電宕機的疑問 解決方案 軟體 實現上電後看門狗的復位 void PowerUpReset(void) { Uint16 Temp_WD = 0; if((SysCtrlRegs.WDCR &am

linux檢視java程序cpu佔用過

 linux下查詢java程序佔用CPU過高原因1. 查詢程序top檢視程序佔用資源情況明顯看出java的兩個程序22714,12406佔用過高cpu. 2.查詢執行緒使用top -H -p <pid>檢視執行緒佔用情況 3.查詢java的堆疊資訊將執行緒id轉換成十

notification使用不當導致重啟問題分析(Could not copy bitmap to parcel blob. )

前言 前段時間遇到了一個宕機重啟問題,比較複雜,涉及到多方面的知識,我也分析了很長的時間,期間學到了很多東西,現在把分析的過程整理一下,希望可以給大家一點幫助和啟發,同時也幫助自己再鞏固一下。 一、問題的復現 首先說一下問題最開始的分析思路以及復現的過程,log 中最核心的部

如何在不會導致伺服器的情況下,用 PHP 讀取大檔案

作為PHP開發人員,我們並不經常需要擔心記憶體管理。PHP 引擎在我們背後做了很好的清理工作,短期執行上下文的 Web 伺服器模型意味著即使是最潦草的程式碼也不會造成持久的影響。 很少情況下我們可能需要走出這個舒適的地方 ——比如當我們試圖在一個大型專案上執行 Co

Redis Cluster節點伺服器導致叢集重啟失敗案例

這裡說下自己碰到的一種情況: redis cluster叢集由三個節點伺服器組成,一個6個redis例項,每個節點開啟2個埠,三主三從。reids部署目錄是/data/redis-4.0.1,叢集情況如下: 172.16.50.245:7000 master主節點 1