內核態與用戶態是操作系統的兩種運行級別，intelcpu提供RingO-Ring3三種級別的運行模式。RingO級別最高，Ring3最低。當一個任務（進程）執行系統調用而陷入內核代碼中執行時，我們就稱進程處于內核運行態（或簡稱為內核態）。此時處理器處于特權級最高的（0級）內核代碼中執行。當進程處于內核態時，執行的內核代碼會使用當前進程的內核棧。每個進程都有自己的內核棧。當進程在執行用戶自己的代碼時，則稱其處于用戶運行態（用戶態）。即此時處理器在特權級最低的（3級）用戶代碼中運行。在內核態下CPU可執行任何指令，在用戶態下CPU只能執行非特權指令。當CPU處于內核態，可以隨意進入用戶態；而當CPU處于用戶態時，用戶從用戶態切換到內核態只有在系統調用和中斷兩種情況下發生，一般程序一開始都是運行于用戶態，當程序需要使用系統資源時，就必須通過調用軟中斷進入內核態。現象壓力測試過程中，發現被測對象性能不夠理想，具體表現為：進程的系統態CPU消耗20,用戶態CPU消耗10,系統idle大約70用ps-omajflt,minflt-Cprogram命令查看，發現majflt每秒增量為0，而minflt每秒增量大于10000。初步分析majflt代表majorfault，中文名叫大錯誤，minflt代表minorfault，中文名叫小錯誤。這兩個數值表示一個進程自啟動以來所發生的缺頁中斷的次數。當一個進程發生缺頁中斷的時候，進程會陷入內核態，執行以下操作：檢查要訪問的虛擬地址是否合法查找/分配一個物理頁填充物理頁內容（讀取磁盤，或者直接置0，或者啥也不干）建立映射關系（虛擬地址到物理地址）重新執行發生缺頁中斷的那條指令如果第3步，需要讀取磁盤，那么這次缺頁中斷就是majflt，否則就是minflto此進程minflt如此之高，一秒10000多次，不得不懷疑它跟進程內核態cpu消耗大有很大關系。分析代碼查看代碼，發現是這么寫的：一個請求來，用malloc分配2M內存，請求結束后free這塊內存。看日志，發現分配內存語句耗時10us，平均一條請求處理耗時1000us。原因已找到！雖然分配內存語句的耗時在一條處理請求中耗時比重不大，但是這條語句嚴重影響了性能要解釋清楚原因，需要先了解一下內存分配的原理。內存分配的原理從操作系統角度來看，進程分配內存有兩種方式，分別由兩個系統調用完成：brk和mmap（不考慮共享內存）。brk是將數據段（.data）的最高地址指針_edata往高地址推，mmap是在進程的虛擬地址空間中（一般是堆和棧中間）找一塊空閑的。這兩種方式分配的都是虛擬內存，沒有分配物理內存。在第一次訪問已分配的虛擬地址空間的時候，發生缺頁中斷，操作系統負責分配物理內存，然后建立虛擬內存和物理內存之間的映射關系。

在標準C庫中，提供了malloc/free函數分配釋放內存，這兩個函數底層是由brk，mmapmunmap這些系統調用實現的。下面以一個例子來說明內存分配的原理：1進程啟動的時候，其（虛擬）內存空間的初始布局如圖1所示。其中，mmap內存映射文件是在堆和棧的中間（例如libc-2.2.93.so，其它數據文件等），為了簡單起見，省略了內存映射文件。—edata指針（glibc里面定義）指向數據段的最高地址。2進程調用A=malloc（30K）以后，內存空間如圖2：malloc函數會調用brk系統調用，將_edata指針往高地址推30K，就完成虛擬內存分配。你可能會問：只要把_edata+3OK就完成內存分配了？事實是這樣的，_edata+30K只是完成虛擬地址的分配，A這塊內存現在還是沒有物理頁與之對應的，等到進程第一次讀寫A這塊內存的時候，發生缺頁中斷，這個時候，內核才分配A這塊內存對應的物理頁。也就是說，如果用malloc分配了A這塊內容，然后從來不訪問它，那么，A對應的物理頁是不會被分配的。3進程調用B=malloc（40K）以后，內存空間如圖3.(icxi>堆A目40KC一*14+iiWflSxfrffiTfff代同段［血mSt畑皿IM塔AJOKn-4f)Kd-ia?KC-2*0K*拽崙堆JIaKfffffrrF0=fjHoc卩陽)冊闕SO附代碼舉i.kxl)堆23QK：R/MtD-3-lfflKTX檻Steffi⑹■fr?(C)4進程調用C=malloc(200K)以后，內存空間如圖4：默認情況下，malloc函數分配內存，如果請求內存大于128K(可由M_MMAP_THRESHOLD選項調節)，那就不是去推_edata指針了，而是利用mmap系統調用，從堆和棧的中間分配一塊虛擬內存。這樣子做主要是因為brk分配的內存需要等到高地址內存釋放以后才能釋放(例如，在B釋放之前，A是不可能釋放的)，而mmap分配的內存可以單獨釋放。當然，還有其它的好處，也有壞處，再具體下去，有興趣的同學可以去看glibc里面malloc的代碼了。5進程調用D=malloc(100K)以后，內存空間如圖5.6進程調用free(C)以后，C對應的虛擬內存和物理內存一起釋放

(6:電址mnsjiLj 昭KIW闌昭日00餐碼謹(JCXE9蠱H段r.da(n；畝報睡3血)舷険(Ma)A-30Kh-JQKA-30K斗? ―k\)1WK11pjjk*時試葩川簡血iLSMffffffffaxffffffff0T(ffffFffF忖)(?>fre?(D)trim7進程調用free(B)以后，如圖7所示。B對應的虛擬內存和物理內存都沒有釋放，因為只有一個_edata指針，如果往回推，那么D這塊內存怎么辦呢？當然，B這塊內存，是可以重用的，如果這個時候再來一個40K的請求，那么malloc很可能就把B這塊內存返回回去了。8進程調用free(D)以后，如圖8所示。B和D連接起來，變成一塊140K的空閑內存。9默認情況下：當最高地址空間的空閑內存超過128K(可由M_TRIM_THRESHOLD選項調節)時，執行內存緊縮操作(trim)。在上一個步驟free的時候，發現最高地址空閑內存超過128K,于是內存緊縮，變成圖9所示。真相大白說完內存分配的原理，那么被測模塊在內核態cpu消耗高的原因就很清楚了：每次請求來都malloc一塊2M的內存，默認情況下，malloc調用mmap分配內存，請求結束的時候，調用munmap釋放內存。假設每個請求需要5個物理頁，那么每個請求就會產生5個缺頁中斷，在2000的壓力下，每秒就產生了10000多次缺頁中斷，這些缺頁中斷不需要讀取磁盤解決，所以叫做minflt；缺頁中斷在內核態執行，因此進程的內核態cpu消耗很大。缺頁中斷分散在整個請求的處理過程中，所以表現為分配語句耗時(10us)相對于整條請求的處理時間(1000us)比重很小。解決辦法將動態內存改為靜態分配，或者啟動的時候，用malloc為每個線程分配，然后保存在threaddata里面。但是，由于這個模塊的特殊性，靜態分配，或者啟動時候分配都不可行。另外，Linux下默認棧的大小限制是10M，如果在棧上分配幾M的內存，有風險。禁止malloc調用mmap分配內存，禁止內存緊縮。在進程啟動時候，加入以下兩行代碼：mallopt(M_MMAP_MAX,0);//禁止malloc調用mmap分配內存mallopt(M_TRIM_THRESHOLD,-1);//禁止內存緊縮效果：加入這兩行代碼以后，用ps命令觀察，壓力穩定以后，majlt和minflt都為0。進程的系統態cpu從20降到10。小結可以用命令ps-omajfltminflt-Cprogram來查看進程的majflt,minflt的值，這兩個值都是累加值，從