進程kswapd0與events/0消耗大量CPU的問題
今天下午網站宕了兩次機，發工單給阿里云，發現原因是服務器的CPU 100%了。
重啟服務器后，使用 top 命令看看是哪些進程消耗那么大的 CPU 使用。盯了有好十幾分鐘，主要消耗 CPU 的進程有兩個，一個是 mysql，另一個是 apache。下面的圖可以看到，mysql 占用了很大部分的 CPU 使用。apache 單個進程雖然占得不多，但有不少個 apache 進程同時存在，也消耗了不少 CPU 的使用。
當然，這些不足以讓服務器的 CPU 直接跑滿掛掉，后來發現了兩個大家伙：
當 mysql 的 CPU 消耗降下來之后，出現了兩個奇怪的進程：kswapd0 和 events/0。
1. kswapd0
| Linux uses kswapd for virtual memory management such that pages that have been recently accessed are kept in memory and less active pages are paged out to disk. (what is a page?)…Linux uses manages memory in units called pages. So,the kswapd process regularly decreases the ages of unreferenced pages…and at the end they are paged out(moved out) to disk |
kswapd0進程的作用：它是虛擬內存管理中，負責換頁的，操作系統每過一定時間就會喚醒kswapd ，看看內存是否緊張，如果不緊張，則睡眠，在 kswapd 中，有2 個閥值，pages_hige 和 pages_low，當空閑內存頁的數量低于 pages_low 的時候，kswapd進程就會掃描內存并且每次釋放出32 個free pages，直到 free page 的數量到達pages_high。
查看內存使用率，發現內存確實不夠用，有時候已經使用到了swap。
2. events/0
另一個進程 events/0 是工作者線程，主要是用來執行delay work的。先簡單介紹一下。
我們都知道中斷的底半部機制有三種：軟中斷、tasklet和工作隊列。其中軟中斷很少使用，內核中只有網絡在使用，它的延時是最小的。
tasklet是軟中斷的一個應用，所有線程注冊的tasklet都會順序被執行。因此tasklet的執行環境是軟中斷上下文，所以不能阻塞或者睡眠。一般情況下，tasklet的延遲也很小，可以滿足大部分需求。
要是底半部中可能睡眠，那么只好使用工作隊列了。工作隊列其實是把要做的底半部的函數交給內核的專門線程去調用。這樣工作隊列就運行于線程環境了，不怕睡眠。當然，睡眠會影響注冊到同一線程的其它底半部的執行，但不會引起大的問題。每個CPU都有一個線程（events/n,n是編號）負責執行工作隊列，第一個CPU的線程是events/0，如果是雙核的，還會有一個events/1線程。程序使用了工作隊列，所以每次執行都會多出一個events/0(第一個CPU上工作線程)。
內核的軟中斷輔助處理線程ksoftirqd/n(n是CPU編號)，它們負責出發軟中斷中觸發的軟中斷。它們將重新觸發軟中斷放在系統空閑時調用，而不是馬上。這樣用戶空間不至于饑餓，重新觸發的軟中斷也得以盡快執行。（《Linux內核設計與實現》85頁）
宕機原因顯而易見了，physical mem 不足，引起 swap 頻繁。其實這也是 VPS 使用上的一個常見的問題了，通常是由 Apache 占用內存過多引起的。kswapd0 是系統的虛擬內存管理程序，如果物理內存不夠用，系統就會喚醒 kswapd0 進程，由 kswapd0 分配磁盤交換空間作緩存，因而占用大量的 CPU 資源。重啟Apache，釋放內存，問題就會消失。但這不是長久之計，最好的方法還是花點錢升級下內存。我也知道隨著訪問量的不斷上漲，肯定要升級下內存，但是沒想到這個問題這么快就來了……
吐槽一下，雖然網站現在的規模也不算很大，但是慢慢也開始吃服務器的硬件了。CPU和內存接下來也需要升級，一個人維護這么一個站點還真的各種操心。
