1. 先把三個詞的邊界劃清楚虛擬內(nèi)存、物理內(nèi)存與進(jìn)程地址空間線上告警一響很多人第一反應(yīng)是敲 top看到 used 高就慌看到 free 少就想加內(nèi)存條。這套反應(yīng)我早年也走過后來被一位老運(yùn)維按住手先把 VSZ、RSS、available 三個數(shù)讀明白再決定要不要動刀。 Linux 內(nèi)存管理這件事繞不開虛擬內(nèi)存、物理內(nèi)存、進(jìn)程地址空間這三個概念——它們是整塊拼圖的骨架也是面試和實戰(zhàn)里被問得最多、錯得最多的部分。虛擬內(nèi)存給進(jìn)程發(fā)的是提貨憑證物理內(nèi)存才是真正堆貨的倉庫而進(jìn)程地址空間就是每本憑證上標(biāo)注的取貨范圍。三者的配合一旦理解錯你看到的每一個數(shù)字都會騙你。這篇內(nèi)容偏向?qū)崙?zhàn)拆解適合三類人剛?cè)胄胁痪谩⒈籪ree輸出繞暈的運(yùn)維新人寫 C/C、Go、Java 服務(wù)想搞清楚自己進(jìn)程到底吃多少內(nèi)存的后端開發(fā)以及準(zhǔn)備系統(tǒng)方向面試、需要把碎片知識串成一條線的同學(xué)。我不會一上來就甩源碼結(jié)構(gòu)體而是先講清楚為什么要這么設(shè)計再落到可以親手敲的命令和參數(shù)最后把踩過的坑攤開說。1.1 用一個借書證類比三者的分工想象一座城市的圖書館。每一本書有固定的架位號這是物理地址但圖書館不會讓讀者直接沖進(jìn)書庫亂翻而是給每人發(fā)一張借書證證上寫的是第 3 排第 5 層左手第二本這樣的虛擬地址。讀者拿著證去前臺前臺查一張對照表把編號翻譯成真實架位再把書遞出來。這張對照表就是頁表負(fù)責(zé)翻譯的前臺就是MMU內(nèi)存管理單元集成在 CPU 里而借書證上的那個可用編號范圍就是進(jìn)程地址空間。這個類比里最關(guān)鍵的一點(diǎn)是每位讀者的借書證編號都從 1 開始互相看不見對方。進(jìn)程 A 眼里的 0x400000 和進(jìn)程 B 眼里的 0x400000完全是兩個不同的物理位置。地址隔離這件事帶來的收益遠(yuǎn)超成本——沒有它一個程序?qū)懺浇缇湍芨膲牧硪粋€程序的數(shù)據(jù)操作系統(tǒng)就得回到單道批處理的年代。另一個隱性收益是稀疏使用你申請 1GB 內(nèi)存內(nèi)核立刻給你 1GB 虛擬地址區(qū)間但物理頁要等你真正寫到那一頁才分配這叫按需分頁demand paging。很多程序申請了 1GB實際只用了 100MB靠的就是這套機(jī)制活著。1.2 用戶態(tài)、內(nèi)核態(tài)、硬件三層各管一段Linux 內(nèi)存管理的代碼橫跨三個層次理清分層之后看源碼才不迷路。最上層是用戶態(tài)接口malloc、mmap、brk、shmget這些屬于 libc 和系統(tǒng)調(diào)用層進(jìn)程能直接感知中間層是內(nèi)核的內(nèi)存管理子系統(tǒng)它負(fù)責(zé)維護(hù)進(jìn)程地址空間mm_struct、vm_area_struct、管理物理頁框struct page、做頁表映射和缺頁處理mm/目錄下那幾萬行代碼全在這里最下層是硬件包括 MMU、TLB快表、各級緩存它們按照頁表給出的規(guī)則默默工作內(nèi)核只能通過 TLB 刷新指令如invlpg和緩存控制指令去影響它。理解這個分層帶來的直接好處是以后看到內(nèi)存沒釋放你先判斷問題出在哪一層。用戶態(tài)malloc沒調(diào)free那是應(yīng)用層泄漏free調(diào)了但 RSS 不降可能是 glibc 沒把內(nèi)存還給內(nèi)核arena 緩存內(nèi)核層 slab 緩存持續(xù)增長得用slabtop去看具體哪個緩存項在膨脹再往下如果是頁表本身占得太多那就是映射數(shù)量爆炸vm.max_map_count相關(guān)。不同的層有不同的觀察工具用錯工具等于白忙一場。2. 進(jìn)程地址空間是怎么被畫出來的從一次 malloc 說起一個 C 程序啟動之后內(nèi)核給它準(zhǔn)備了一整套虛擬地址布局代碼段、數(shù)據(jù)段、BSS、堆、棧、共享庫映射區(qū)、內(nèi)核映射區(qū)每一塊都有明確的范圍和權(quán)限。這套布局不是拍腦袋定的而是幾十年演進(jìn)下來的折中結(jié)果——既要給共享庫留出足夠的隨機(jī)化空間ASLR又要讓brk擴(kuò)展堆的路徑盡量短還得給棧留出向低地址生長的余量。想搞懂valgrind、pmap、/proc/PID/maps輸出的那些行到底代表什么先得把這張布局圖刻在腦子里。2.1 32 位與 64 位的地址空間布局差在哪32 位時代最經(jīng)典的劃分是03GB 給用戶34GB 給內(nèi)核也就是 1:3 的分割比例。這個比例在 4GB 物理內(nèi)存的機(jī)器上剛剛好內(nèi)存一漲到 8GB、16GB內(nèi)核就不得不用HIGHMEM高端內(nèi)存來做臨時映射才能訪問到全部物理內(nèi)存——因為內(nèi)核能直接線性映射的虛擬地址只有 1GB。這是 32 位系統(tǒng)的歷史包袱也是為什么很多老服務(wù)在 32 位環(huán)境下會出現(xiàn)明明內(nèi)存夠用卻分配失敗的怪現(xiàn)象。x86-64 下事情寬松多了。當(dāng)前主流是四級頁表、48 位虛擬地址用戶空間和內(nèi)核空間各占 128TB0x0000_0000_0000_0000到0x0000_7fff_ffff_ffff是用戶態(tài)高地址一半是內(nèi)核態(tài)。128TB 什么概念你可以在一臺 16GB 物理內(nèi)存的機(jī)器上讓一個進(jìn)程映射 100TB 的虛擬內(nèi)存而毫無壓力——只要不去寫它。這也是容器和 JVM 敢把虛擬地址空間規(guī)劃得那么大的底氣所在。近幾年 5 級頁表LA57開始在新硬件上鋪開虛擬地址擴(kuò)大到 57 位用戶空間漲到 64PB但那是給超大規(guī)模內(nèi)存場景準(zhǔn)備的日常碰不到。需要注意的是 ASLR地址空間布局隨機(jī)化。同一份代碼跑兩次棧基址、共享庫基址、堆基址都會不一樣這是內(nèi)核故意加的安全特性。調(diào)試時如果發(fā)現(xiàn)某次崩潰地址和上次對不上別急著懷疑人生先cat /proc/sys/kernel/randomize_va_space看一眼是不是 2完全隨機(jī)化。臨時定位問題時可以設(shè)為 0 復(fù)現(xiàn)但生產(chǎn)環(huán)境千萬別關(guān)。2.2 mm_struct 與 vm_area_struct內(nèi)核眼里的進(jìn)程內(nèi)存地圖內(nèi)核怎么描述一個進(jìn)程的內(nèi)存答案是一主多從的數(shù)據(jù)結(jié)構(gòu)。mm_struct是總賬本每個進(jìn)程一個線程之間共享里面記錄著整個地址空間的起止范圍、各段起始地址start_code、end_code、start_data、start_brk、brk、start_stack、頁表根指針pgd、映射區(qū)域的紅黑樹根mm_rb、VMA 鏈表頭mm_mmap以及駐留集統(tǒng)計rss_stat。vm_area_struct簡稱 VMA是分賬明細(xì)每一段連續(xù)、權(quán)限相同的虛擬區(qū)間對應(yīng)一個 VMA記錄vm_start、vm_end、vm_flags讀/寫/執(zhí)行/共享、vm_file如果是文件映射和vm_ops操作函數(shù)集。一個普通進(jìn)程有多少個 VMA空殼程序大概十幾個一個跑著 JVM 或者帶了幾十個.so的服務(wù)幾百到幾千個都正常。/proc/PID/maps里每一行就是一個 VMA/proc/PID/maps的行數(shù)直接等于 VMA 數(shù)量。為什么要用紅黑樹加鏈表兩套結(jié)構(gòu)因為查找方式不同——按地址查找 VMA缺頁時用走紅黑樹O(log n)順序遍歷全部映射fork時復(fù)制、munmap時檢查走鏈表。內(nèi)核里這種一套數(shù)據(jù)、兩種索引的設(shè)計非常常見看到類似結(jié)構(gòu)別覺得冗余先想清楚兩個訪問路徑分別是誰在用。VMA 還有一個容易被忽略的作用它承載了分配語義。當(dāng)進(jìn)程調(diào)用malloc(1MB)時glibc 通常走mmap內(nèi)核創(chuàng)建一個新的匿名 VMA權(quán)限是讀寫、不關(guān)聯(lián)文件而malloc(16)走的是堆擴(kuò)展改寫的是brk指針VMA 只是被拉伸或合并。這就是為什么同一份程序里不同大小的分配在/proc/PID/maps里表現(xiàn)完全不同。2.3 malloc 到底是走 brk 還是 mmap這是被問得最多的問題之一答案是有閾值。glibc 默認(rèn)的M_MMAP_THRESHOLD是128KB小于它的分配從堆上切brk區(qū)域大于等于它的走mmap單獨(dú)映射一個匿名段。這個閾值不是固定的glibc 有動態(tài)調(diào)整機(jī)制當(dāng)你free掉一塊大于當(dāng)前閾值的 mmap 內(nèi)存時閾值會被抬高到那塊內(nèi)存的大小上限 32MB64 位。這個動態(tài)機(jī)制是為了避免大塊分配、釋放、再分配反復(fù)觸發(fā) mmap/munmap 系統(tǒng)調(diào)用。分配方式典型觸發(fā)條件釋放行為常見觀察現(xiàn)象brk小塊 128KB不一定歸還內(nèi)核可能留在 arenaRSS 不降VSZ 穩(wěn)定mmap匿名映射大塊≥ 128KBfree后通常直接munmapRSS 立即下降mmap文件映射mmap()顯式調(diào)用依賴引用計數(shù)與msync計入Mapped字段實操上有個細(xì)節(jié)值得記查看閾值可以用MALLOC_MMAP_THRESHOLD_環(huán)境變量覆蓋也可以用mallopt(M_MMAP_THRESHOLD, size)在代碼里調(diào)。我處理過一個日志服務(wù)的 RSS 緩慢增長問題最后定位到就是頻繁分配 100KB200KB 的緩沖區(qū)正好卡在閾值邊緣來回震蕩導(dǎo)致 arena 里堆了一片無法回收的碎片。把緩沖區(qū)改成固定大小的對象池之后RSS 曲線立刻拉平。提示glibc的多線程分配有一個常被忽略的設(shè)定——arena 數(shù)量默認(rèn)是8 × CPU 核數(shù)64 位下。每個線程第一次分配內(nèi)存時可能綁定到一個新 arena而單個 arena 在 64 位下的虛擬地址上限是 64MB。線程多、分配頻繁的服務(wù)光 arena 的虛擬地址占用就可能上千 MB。設(shè)MALLOC_ARENA_MAX2~4往往能顯著壓低 VSZ 和碎片代價是極端并發(fā)下鎖競爭會變強(qiáng)。3. 虛擬地址到物理地址的那一跳頁表、MMU 與缺頁異常前面說的都是賬本現(xiàn)在看翻譯這一步。CPU 執(zhí)行指令時拿到的是虛擬地址必須經(jīng)過 MMU 翻譯成物理地址才能訪問內(nèi)存。翻譯的依據(jù)是頁表翻譯的結(jié)果被緩存進(jìn) TLB。翻譯過程中如果發(fā)現(xiàn)缺少映射或者權(quán)限不符硬件會拋出一個缺頁異常page fault把控制權(quán)交給內(nèi)核的do_page_fault由內(nèi)核決定是補(bǔ)一頁、換一頁還是直接給進(jìn)程發(fā) SIGSEGV。這一步是整個內(nèi)存管理里唯一每次訪存都要走的路徑它的效率直接決定程序性能。3.1 多級頁表與 TLB為什么不做一本大字典最樸素的想法是一張大表把 48 位虛擬地址全映射一遍。算一下就知道不行——48 位地址空間、4KB 頁大小需要 2^36 個頁表項每項 8 字節(jié)合計 512GB。每個進(jìn)程一張內(nèi)存直接爆掉。真實做法是多級頁表x86-64 四級頁表把 48 位虛擬地址切成PGD(9) PUD(9) PMD(9) PTE(9) 頁內(nèi)偏移(12)每一級 512 項。關(guān)鍵在于按需分配進(jìn)程只用了幾百 MB 內(nèi)存那么絕大部分 PGD 表項是空的下面的 PUD/PMD/PTE 表根本不存在。稀疏結(jié)構(gòu)換空間這是多級頁表存在的唯一理由。代價是訪存次數(shù)。一次翻譯理論上要走 4 次內(nèi)存讀取每級頁表一次加上真正取數(shù)據(jù)那次一次訪存變五次性能直接腰斬。所以 CPU 里塞了 TLB——一個幾十到幾百項的高速緩存專門存最近用過的虛擬頁到物理頁的映射。TLB 命中時翻譯是零開銷的。TLB 有多大典型的數(shù)據(jù) TLB 一級緩存 64 項左右二級 15002000 項。這組數(shù)字解釋了一個現(xiàn)象頻繁訪問大范圍、隨機(jī)分布的地址TLB 命中率會崩性能隨之驟降。這也是大頁HugePage能提速的根本原因——一個 2MB 大頁只用一項 TLB 覆蓋 512 倍于 4KB 頁的范圍。3.2 缺頁異常的三種典型面孔缺頁異常不是錯誤是正常流程。它至少有三種形態(tài)用ps -o maj_flt,min_flt或者/proc/PID/stat的對應(yīng)字段能看到計數(shù)。類型觸發(fā)條件內(nèi)核動作代價次缺頁minor fault頁已在內(nèi)存只是當(dāng)前進(jìn)程沒有映射建立頁表項建立反向映射微秒級主缺頁major fault頁不在內(nèi)存需從磁盤/swap 讀入發(fā)起 I/O阻塞等待毫秒級慢 1000 倍非法訪問地址未映射或權(quán)限不符發(fā)送 SIGSEGV / SIGBUS進(jìn)程終止次缺頁最常見的場景是fork之后子進(jìn)程第一次寫內(nèi)存以及匿名內(nèi)存首次被寫。主缺頁則和文件讀取、swap 換入強(qiáng)相關(guān)。判斷一個服務(wù)的性能瓶頸是不是內(nèi)存導(dǎo)致看一眼主缺頁率就能篩掉一大半可能性——如果maj_flt每秒幾百上千次說明系統(tǒng)正在反復(fù)從磁盤撈數(shù)據(jù)內(nèi)存明顯不夠用了。注意maj_flt計數(shù)是累計值別直接看絕對值。正確做法是間隔采樣算差值cat /proc/PID/stat | awk {print $12, $10}取兩次除上間隔秒數(shù)得到每秒速率。這個坑我見太多人踩了。3.3 fork 為什么快寫時復(fù)制的賬怎么算fork一個占 2GB 內(nèi)存的進(jìn)程理論上要復(fù)制 2GB 數(shù)據(jù)實際上幾毫秒就返回了。原因就是寫時復(fù)制Copy-On-WriteCOW。fork時內(nèi)核并不復(fù)制物理頁只復(fù)制頁表——父子的頁表項都指向同一批物理頁同時把這些頁標(biāo)記為只讀。誰先寫誰觸發(fā)一次缺頁內(nèi)核此時才真正復(fù)制一頁出來改好頁表、恢復(fù)可寫。這套機(jī)制帶來的第一個后果是父子進(jìn)程共用未修改的內(nèi)存實際物理占用遠(yuǎn)小于 2×2GB。第二個后果更微妙——fork之后立刻exec啟動新程序那么 COW 復(fù)制的頁幾乎全被丟棄等于白做。所以現(xiàn)代啟動子進(jìn)程的場景更推薦posix_spawn或者vfork能繞開這一層。COW 還有一個隱形成本容易被低估頁表本身的復(fù)制。大內(nèi)存進(jìn)程的頁表可能有幾十 MBfork時這部分是要實打?qū)崗?fù)制的。所以一個進(jìn)程如果映射了 100GB 的稀疏地址空間比如 JVM 堆預(yù)留fork出來的子進(jìn)程光是頁表拷貝就要花掉幾十毫秒。高頻fork的場景比如老式 CGI、某些 PHP-FPM 配置性能差很多時候根子在這里。4. 物理內(nèi)存怎么發(fā)出去伙伴系統(tǒng)、slab 與頁緩存虛擬地址講完了該看真實的物理頁怎么管。Linux 的物理內(nèi)存管理是分層的從上往下依次是 NUMA 節(jié)點(diǎn)、內(nèi)存區(qū)域zone、頁框page分配時從伙伴系統(tǒng)拿整頁小對象則走 slab 分配器從頁里切。除此之外還有一大塊內(nèi)存被頁緩存占用它既不是某個進(jìn)程的私有財產(chǎn)也不能簡單地算作已用。絕大多數(shù)關(guān)于內(nèi)存的誤判都發(fā)生在沒搞清楚這個數(shù)字屬于哪一層上。4.1 node、zone、page物理內(nèi)存的三層組織最頂層是節(jié)點(diǎn)node對應(yīng) NUMA 架構(gòu)里的一個 CPU 內(nèi)存控制器。單路機(jī)器通常只有一個 node雙路服務(wù)器有兩個。每個節(jié)點(diǎn)用pglist_data描述節(jié)點(diǎn)內(nèi)再劃分 zone。zone 的劃分是歷史遺留和硬件限制的產(chǎn)物ZONE_DMA給那些只能做 24 位尋址的老式外設(shè)用通常在 16MB 以下現(xiàn)代系統(tǒng)基本空著。ZONE_DMA32只能做 32 位尋址的設(shè)備用x86-64 上常見。ZONE_NORMAL常規(guī)內(nèi)存絕大多數(shù)內(nèi)核分配都從這里來。ZONE_HIGHMEM32 位時代的高端內(nèi)存64 位系統(tǒng)上不存在。ZONE_MOVABLE為內(nèi)存熱插拔和減少碎片預(yù)留的可遷移區(qū)。每個 zone 內(nèi)部用free_area[MAX_ORDER]數(shù)組管理空閑頁MAX_ORDER默認(rèn)是 11對應(yīng)最大 4MB 的連續(xù)塊2^10 × 4KB。每個物理頁有一個struct page描述符典型的 64 字節(jié)大小。算一下16GB 內(nèi)存、4KB 頁共 400 萬個頁光是struct page數(shù)組就要吃掉 256MB。這就是為什么內(nèi)核會選擇用vmemmap把struct page數(shù)組映射成一個緊湊的虛擬連續(xù)區(qū)域——節(jié)省的是 TLB 和尋址開銷。4.2 伙伴系統(tǒng)與內(nèi)存碎片伙伴系統(tǒng)的核心思想是按 2 的冪次分配。你要 3 個頁它給你 4 個頁的塊你要 5 個頁它給你 8 個頁。釋放時如果伙伴塊也空閑就合并成更大的塊向上遞歸。這保證了分配和釋放都是 O(log n)也保證了總能找到盡可能大的連續(xù)塊。問題是長期運(yùn)行后不可避免的外部碎片?？臻e頁總數(shù)可能還有 1GB但沒有一塊連續(xù)的 4MB需要大塊連續(xù)內(nèi)存的分配比如某些 DMA 緩沖區(qū)、大頁申請就會失敗。內(nèi)核提供了兩個應(yīng)對手段內(nèi)存壓縮compaction把可遷移頁挪走騰出連續(xù)區(qū)域以及ZONE_MOVABLE機(jī)制把可遷移和不可遷移的頁分開放。看碎片情況直接用/proc/buddyinfo$ cat /proc/buddyinfo Node 0, zone DMA 1 1 1 0 2 1 1 0 1 1 3 Node 0, zone DMA32 1234 1088 823 512 301 188 102 61 30 11 4 Node 0, zone Normal 30012 20114 12003 6102 3011 1502 701 312 140 55 12每一列表示該 order 下的空閑塊數(shù)量order 0 是 4KB 單頁order 10 是 4MB 塊。如果左邊幾列數(shù)字很大、右邊幾列接近 0說明系統(tǒng)碎片嚴(yán)重遇到需要大塊連續(xù)內(nèi)存的分配就可能失敗即使總空閑量看起來還很充裕。這個現(xiàn)象在老機(jī)器上的典型表現(xiàn)是fork或者mmap大頁時報 ENOMEM。4.3 slab/slub 與 kmalloc小對象怎么省著花內(nèi)核自己要分配的對象大多很小task_struct、dentry、inode、網(wǎng)絡(luò)套接字緩沖區(qū)都是幾百字節(jié)。如果每個都占一整頁 4KB浪費(fèi)太夸張。slab 分配器就是為了切頁而生它從伙伴系統(tǒng)拿整頁按對象大小切成等份用空閑鏈表管理。同一個緩存里的對象類型相同初始化一次可以反復(fù)復(fù)用。Linux 歷史上有三種實現(xiàn)slab、slub、slob。現(xiàn)在主流是slub代碼更簡潔、調(diào)試友好、在大型系統(tǒng)上擴(kuò)展性更好。查看方式$ sudo slabtop -o -s c | head -15 Active / Total Objects (% used) : 2891234 / 3120987 (92.6%) Active / Total Slabs (% used) : 98234 / 98234 (100.0%) Active / Total Caches (% used) : 118 / 165 (71.5%) Active / Total Size (% used) : 512345.67K / 561234.12K (91.3%) Minimum / Average / Maximum Object : 0.01K / 0.29K / 8.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 892500 882301 98% 0.19K 42500 21 3400000K dentry 621400 601200 96% 1.05K 31070 20 2485600K ext4_inode_cache ...dentry和inode緩存排在前兩名是極其正常的現(xiàn)象它們會隨著文件訪問自然增長也會在內(nèi)存壓力下被回收——注意SReclaimable和SUnreclaim的區(qū)別前者能還后者不能還。如果某天發(fā)現(xiàn)SUnreclaim持續(xù)漲而不落那才是真問題一般是某個內(nèi)核模塊的緩存泄漏。實操心得kmalloc和vmalloc的區(qū)別值得記住。kmalloc從線性映射區(qū)分配物理連續(xù)速度快但大小受限一般不超過 4MBvmalloc只保證虛擬連續(xù)物理上可以不連續(xù)代價是多一層頁表和多一次 TLB 未命中。寫驅(qū)動或者看內(nèi)核日志時看到vmalloc分配失敗但內(nèi)存還有富余八成是虛擬地址空間不夠x86-64 上 32TB 左右得查/proc/vmallocinfo。4.4 頁緩存、臟頁回寫與回收水位文件讀寫不會直接落到磁盤中間隔著頁緩存page cache。讀的時候內(nèi)核先把文件頁讀進(jìn)內(nèi)存下次讀同一塊直接命中內(nèi)存寫的時候先寫進(jìn)內(nèi)存里對應(yīng)的頁標(biāo)記為臟頁dirty再由pdflush/writeback內(nèi)核線程批量刷回磁盤。這就是為什么free輸出里buff/cache常年占大頭也是為什么很多內(nèi)存泄漏的錯覺其實來自頁緩存。臟頁刷盤的策略由兩組 sysctl 控制參數(shù)默認(rèn)值含義vm.dirty_background_ratio10臟頁占內(nèi)存比例超過此值后臺線程開始異步回寫vm.dirty_ratio20超過此值寫操作同步阻塞直到臟頁降下來vm.dirty_expire_centisecs3000臟頁最長駐留時間30 秒vm.dirty_writeback_centisecs500回寫線程喚醒間隔5 秒這兩個 ratio 參數(shù)是很多服務(wù)周期性卡頓的真兇。如果你的服務(wù)在大文件寫入時每幾十秒出現(xiàn)一次幾百毫秒的停頓大概率就是臟頁沖到dirty_ratio觸發(fā)了同步寫回所有寫入線程一起被阻塞。把dirty_ratio調(diào)低比如 5、dirty_background_ratio調(diào)更低比如 2讓回寫更平滑地發(fā)生往往能明顯改善延遲毛刺。代價是磁盤 IO 更頻繁SSD 上這點(diǎn)代價可以忽略?；厥者@部分還涉及水位線機(jī)制。每個 zone 有三個水位WMARK_MIN、WMARK_LOW、WMARK_HIGH由vm.min_free_kbytes決定基準(zhǔn)。空閑頁降到 LOW 以下喚醒kswapd后臺回收降到 MIN 以下任何分配請求都要先自己做一次直接回收direct reclaim這時分配線程會被拖住表現(xiàn)為分配內(nèi)存變慢。這就是內(nèi)存吃緊時服務(wù)響應(yīng)變慢的底層原因而不是 CPU 不夠。5. 動手排查命令和內(nèi)核接口怎么用才不誤判理論說完了進(jìn)入實操。這一節(jié)按看全局 → 看進(jìn)程 → 看細(xì)節(jié)的順序來每條命令都配上怎么讀、容易誤讀在哪。我自己的習(xí)慣是先看free定大方向再用smaps_rollup定具體進(jìn)程最后用smaps或采樣對比找具體區(qū)域。5.1 free、top、ps、pmap 的正確讀法先看free -h的輸出$ free -h total used free shared buff/cache available Mem: 62Gi 28Gi 3.2Gi 1.1Gi 31Gi 32Gi Swap: 8.0Gi 512Mi 7.5Giavailable才是還能給新程序用多少內(nèi)存的答案不是free。free只有 3.2GB 看著嚇人但available有 32GB因為那 31GB 的buff/cache大部分是可回收的頁緩存。這個字段是老版本free沒有的procps 3.3.10 之后才有現(xiàn)在還在用老版本系統(tǒng)的同學(xué)建議順手升級一下工具包能少踩很多坑。再看進(jìn)程級。ps aux里的VSZ和RSS是新手最容易搞混的兩個數(shù)指標(biāo)全稱含義用途VSZ / VIRTVirtual Set Size整個虛擬地址空間大小判斷映射規(guī)模不能當(dāng)內(nèi)存占用量RSS / RESResident Set Size已駐留在物理內(nèi)存的頁大小粗看實際占用但共享頁會重復(fù)計算PSSProportional Set Size共享頁按共享進(jìn)程數(shù)均攤?cè)萜?多進(jìn)程場景更公平USSUnique Set Size進(jìn)程獨(dú)占的物理內(nèi)存判斷進(jìn)程真實私有開銷RSS的坑在于100 個進(jìn)程映射了同一個 200MB 的.so這 200MB 會在每個進(jìn)程的 RSS 里各算一次加起來變成 20GB實際物理上只有一份。容器內(nèi)存限制打不準(zhǔn)、賬單算不清很多時候就栽在這里。想知道真實的均攤值得看PSS$ cat /proc/1234/smaps_rollup Rss: 5123456 kB Pss: 1023456 kB Pss_Anon: 800000 kB Pss_File: 223456 kB Pss_Shmem: 0 kB Shared_Clean: 4000000 kB Private_Dirty: 800000 kB Anonymous: 800000 kB Swap: 0 kBsmaps_rollup是內(nèi)核 4.14 引入的把原來要遍歷整個smaps的統(tǒng)計一次算好代價極低可以放心放進(jìn)監(jiān)控腳本里定期采集。老的smaps文件在大內(nèi)存進(jìn)程上跑一次要幾秒甚至幾十秒監(jiān)控系統(tǒng)里高頻調(diào)用它會直接把系統(tǒng)拖垮這個坑我親身經(jīng)歷過——某次告警腳本每分鐘掃一遍所有 Java 進(jìn)程的smaps導(dǎo)致磁盤 IO 和 CPU 雙雙飆高排查了半天才發(fā)現(xiàn)是監(jiān)控自己干的。5.2 /proc/meminfo 里最容易誤讀的字段/proc/meminfo是內(nèi)核內(nèi)存狀態(tài)的權(quán)威快照字段有六十多個下面挑幾個必須搞明白的$ head -20 /proc/meminfo MemTotal: 65863456 kB MemFree: 3355440 kB MemAvailable: 33000000 kB Buffers: 512000 kB Cached: 30000000 kB SwapCached: 2048 kB Active: 20000000 kB Inactive: 15000000 kB Active(anon): 12000000 kB Inactive(anon): 2000000 kB Active(file): 8000000 kB Inactive(file): 13000000 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 8388608 kB SwapFree: 7864320 kB Dirty: 51200 kB Writeback: 0 kB AnonPages: 14000000 kB Mapped: 512000 kB Shmem: 1100000 kB Slab: 3400000 kB SReclaimable: 2800000 kB SUnreclaim: 600000 kB PageTables: 120000 kB幾個要點(diǎn)Active/Inactive是 LRU 鏈表長度不是活躍內(nèi)存的語義。內(nèi)核回收時會先在 inactive 里挑不夠再把 active 降級?？吹紸ctive(anon)特別大說明匿名內(nèi)存多且訪問密集這部分回收起來要去 swap代價高。AnonPages是所有匿名頁總和包括堆、棧、私有映射。它和Cached是兩大陣營前者是進(jìn)程的后者是文件的。Mapped是文件映射和共享內(nèi)存的總和通常遠(yuǎn)小于Cached因為頁緩存里很多頁只是被讀過沒有被任何進(jìn)程映射。PageTables是頁表本身占用的內(nèi)存。這個值平時幾 MB 到幾十 MB但如果一個進(jìn)程映射了幾十萬個 VMA它能漲到幾 GB。我見過一個內(nèi)存數(shù)據(jù)庫把PageTables頂?shù)?6GB最后發(fā)現(xiàn)是映射數(shù)量爆炸。CommitLimit和Committed_AS在vm.overcommit_memory2時才有強(qiáng)約束意義前者是允許承諾的上限后者是已承諾量。默認(rèn)模式 0 下這兩個值參考價值有限。5.3 幾個 sysctl 參數(shù)的取舍與實操記錄參數(shù)調(diào)優(yōu)最忌諱照抄網(wǎng)上的最佳實踐。同樣一個vm.swappiness1在數(shù)據(jù)庫服務(wù)器上是必要的在內(nèi)存只有 2GB 的老舊虛擬機(jī)上可能是災(zāi)難。下面是我自己反復(fù)驗證過的幾個參數(shù)以及調(diào)整時的判斷依據(jù)。vm.swappiness控制內(nèi)核在回收時更傾向于丟頁緩存還是換出匿名頁。默認(rèn) 60 意味著兩類內(nèi)存被同等對待。數(shù)據(jù)庫、Redis 這類自己管理內(nèi)存的服務(wù)通常希望盡量別換出匿名頁換出后延遲飆升會調(diào)成 110而桌面環(huán)境希望閑置程序盡快換出、給當(dāng)前應(yīng)用讓路可以調(diào)高。改之前先確認(rèn) swap 分區(qū)大小——如果 swap 只有 1GB調(diào)低 swappiness 基本沒意義因為換出空間本來就小。# 臨時生效 sysctl -w vm.swappiness10 # 永久生效 echo vm.swappiness10 /etc/sysctl.d/99-memory.conf sysctl --systemvm.overcommit_memory值得說一下。默認(rèn)值 0 是啟發(fā)式內(nèi)核憑經(jīng)驗判斷這次分配是否離譜1 是永遠(yuǎn)答應(yīng)適合那些自己清楚內(nèi)存用量的場景比如 Redis 官方明確建議設(shè)為 1因為它的 forkCOW 依賴過量承諾2 是嚴(yán)格模式內(nèi)核按公式CommitLimit swap RAM × overcommit_ratio / 100限制承諾總量。嚴(yán)格模式一旦開錯表現(xiàn)是內(nèi)存明明空著fork卻報 Cannot allocate memory排查起來非常反直覺。遇到這類報錯先查這個參數(shù)別急著懷疑物理內(nèi)存。vm.max_map_count默認(rèn) 65530不同內(nèi)核版本有出入用sysctl vm.max_map_count現(xiàn)場確認(rèn)。這個值限制單進(jìn)程 VMA 數(shù)量。跑 Elasticsearch、部分 JVM 應(yīng)用、或者用 mmap 處理超大文件的程序很容易撞上這個限制表現(xiàn)是OutOfMemoryError: Map failed或者mmap: Cannot allocate memory。調(diào)大到 262144 一般是安全的代價是每個 VMA 有約 200 字節(jié)的內(nèi)核開銷。vm.min_free_kbytes決定內(nèi)存回收的水位基準(zhǔn)。默認(rèn)值隨內(nèi)存大小自動計算大內(nèi)存機(jī)器可能算出幾 GB這個值并非越大越好——它直接降低了可用的緩沖空間太小又會導(dǎo)致直接回收頻繁觸發(fā)。我在一臺 128GB 的機(jī)器上把它從默認(rèn)值手動調(diào)到 2GB 后kswapd不再頻繁喚醒但服務(wù)延遲沒有變化說明默認(rèn)值本來就是合適的。沒有明確指標(biāo)支撐的調(diào)參本質(zhì)上是在制造不確定性。6. 高頻坑與排查速查表這一節(jié)講的是知道原理之后依然會錯的地方。這類問題的共同特點(diǎn)是命令都敲對了數(shù)值也都讀到了但結(jié)論錯了。原因通常是沒考慮上下文——是容器還是物理機(jī)是看總量還是看增量是匿名內(nèi)存還是文件緩存。6.1 OOM Killer 為什么挑中了你的進(jìn)程系統(tǒng)內(nèi)存耗盡時oom_killer會挑一個進(jìn)程殺掉。選擇依據(jù)是oom_score計算時考慮幾個因素進(jìn)程的 RSS swap 頁表占用越大越容易被殺、是否為特權(quán)進(jìn)程CAP_SYS_ADMIN等會降分、oom_score_adj調(diào)整值-1000 到 1000。分?jǐn)?shù)越高越容易被殺。查看方式# 看某個進(jìn)程的當(dāng)前分?jǐn)?shù) $ cat /proc/1234/oom_score 847 # 看調(diào)整值 $ cat /proc/1234/oom_score_adj 0最反直覺的一點(diǎn)占內(nèi)存最多的進(jìn)程不一定被殺。因為計算時會做開方rss / total × 1000的平方根縮小了差距再加上其他扣分項實際被殺的常常是內(nèi)存較大但不是最大、又沒有特權(quán)保護(hù)、oom_score_adj還較高的那個。我見過 MySQL 因為配了oom_score_adj -500而幸存旁邊一個只占一半內(nèi)存的日志收集進(jìn)程被干掉事后被業(yè)務(wù)方質(zhì)問為什么殺小的就是這個原因。反過來說如果你想保護(hù)某個關(guān)鍵進(jìn)程做法是# 臨時調(diào)整需要 root echo -900 /proc/$(pidof mysqld)/oom_score_adj # systemd 服務(wù)里永久配置 [Service] OOMScoreAdjust-900別設(shè)成 -1000。-1000 表示完全免疫一旦這個進(jìn)程自己泄漏長成巨獸系統(tǒng)就只能眼睜睜看著它把整機(jī)拖死連最后一道保險都沒了。生產(chǎn)環(huán)境我一般建議 -500 到 -900 之間。6.2 內(nèi)存泄漏與正常增長怎么區(qū)分RSS 一直在漲是最高頻的誤報。要區(qū)分泄漏和正常增長關(guān)鍵是看增長的形態(tài)和歸屬。正常增長通常是啟動后快速爬升到平臺期之后隨業(yè)務(wù)量波動在內(nèi)存壓力出現(xiàn)時能被換出或回收匿名頁進(jìn) swap、頁緩存被丟棄。泄漏的特征是在業(yè)務(wù)量穩(wěn)定的情況下RSS 單調(diào)上漲且不回落kswapd反復(fù)回收也壓不下去最終 OOM。判定的具體操作我一般這么走# 1. 先確認(rèn)增長的是匿名內(nèi)存還是文件緩存 $ awk /^Rss:|^Private_Dirty:|^Private_Clean:|^Shared_Clean:|^Anonymous:|^Swap:/ /proc/PID/smaps_rollup # 2. 間隔采樣算增長速率 $ for i in $(seq 1 10); do grep VmRSS /proc/PID/status; sleep 60; done # 3. 看具體是哪一段在漲 $ cat /proc/PID/smaps | awk /^[0-9a-f]/{addr$0} /^Rss:/{if($210000) print addr, $0} # 4. 用 bcc 的 memleak 抓分配棧需要內(nèi)核支持 $ sudo memleak-bpfcc -p PID -a 60第 3 步是最有價值的。它直接告訴你哪一段虛擬區(qū)間在膨脹結(jié)合區(qū)間名稱[heap]、[anon]還是某個.so基本能鎖定方向。第 4 步的memleak工具需要內(nèi)核 4.9 并安裝 bcc它通過采樣分配調(diào)用棧來定位泄漏點(diǎn)代價是開起來之后會有額外開銷別在生產(chǎn)高峰期隨便用。一個大量服務(wù)都會遇到的假泄漏glibc arena 碎片。表現(xiàn)為 RSS 緩慢上漲但mallinfo顯示uordblks已分配塊穩(wěn)定。這時候不是代碼有問題而是分配模式太碎arena 里到處是沒法合并的空洞。解決辦法是換 jemalloc/tcmalloc或者把MALLOC_ARENA_MAX調(diào)小或者干脆用malloc_trim(0)定期主動歸還。6.3 常見現(xiàn)象速查表下面這張表是我自己排查時常用的對照覆蓋了過去幾年里處理過的大多數(shù)內(nèi)存類問題。列的時候把現(xiàn)象、可能原因、驗證動作、常見處理放在一起方便直接拿去用?，F(xiàn)象可能原因驗證動作常見處理free顯示 free 極少但服務(wù)正常頁緩存占用看MemAvailable是否充足無需處理緩存會自動回收RSS 持續(xù)漲業(yè)務(wù)量不變應(yīng)用泄漏 / arena 碎片smaps分段采樣對比修代碼 / 換分配器 / 調(diào)MALLOC_ARENA_MAXfork報 Cannot allocate memoryovercommit 嚴(yán)格模式 / VMA 上限查vm.overcommit_memory、vm.max_map_count調(diào)整對應(yīng) sysctlmaj_flt速率很高內(nèi)存不足反復(fù)從磁盤/swap 取頁vmstat 1看si/so加內(nèi)存 / 調(diào)swappiness/ 檢查熱點(diǎn)數(shù)據(jù)集服務(wù)周期性卡頓數(shù)百毫秒臟頁同步回寫阻塞vmstat 1看bo尖峰調(diào)低dirty_ratioPageTables漲到 GB 級VMA 數(shù)量過多wc -l /proc/PID/maps減少映射數(shù)合并小映射內(nèi)存充足但進(jìn)程被 OOM 殺cgroup 限制 /oom_score_adjcat /sys/fs/cgroup/.../memory.max調(diào)大限制或調(diào)整 adjSUnreclaim持續(xù)上漲內(nèi)核緩存/模塊泄漏slabtop定位具體緩存升級內(nèi)核 / 卸載問題模塊這張表里的每一條我都至少真實遇到過兩次以上能背下來基本能覆蓋一線大部分場景。剩下的邊角案例靠的是對前面幾節(jié)原理的理解去推。7. 再往里一層容器、大頁與性能觀測前六節(jié)講的都是單機(jī)視角?，F(xiàn)代服務(wù)大量跑在容器里內(nèi)存的可見性和限制方式都變了大頁和高性能場景又會引入另一套機(jī)制。這一節(jié)把這兩塊補(bǔ)上最后講兩個我自己踩過的真實案例。7.1 cgroup 內(nèi)存限制與容器里的 free 陷阱容器通過 cgroup 來限制內(nèi)存。cgroup v1 用的是memory.limit_in_bytesv2 用的是memory.max路徑分別是/sys/fs/cgroup/memory/group/和/sys/fs/cgroup/group/。當(dāng)前用量看memory.usage_in_bytesv1或memory.currentv2。最大的坑是容器里執(zhí)行free看到的是宿主機(jī)的內(nèi)存不是容器的限制。因為/proc/meminfo是內(nèi)核全局?jǐn)?shù)據(jù)沒有做命名空間隔離。一個限制 512MB 的容器里free可能顯示 62GB total于是應(yīng)用啟動時按有 62GB 可用去計算堆大小一啟動就被 OOM 干掉。解決辦法有三種應(yīng)用側(cè)讀取 cgroup 文件而不是/proc/meminfo推薦JVM 從 8u191 之后默認(rèn)這么做參數(shù)-XX:UseContainerSupport掛載 lxcfs 之類的工具它對/proc/meminfo做了一層偽裝讓容器內(nèi)看到經(jīng)過計算的值顯式設(shè)置應(yīng)用的內(nèi)存上限參數(shù)-Xmx、GOMEMLIMIT等不讓它自己猜。第二個要注意的是memory.high和memory.max的區(qū)別。max是硬限制超了直接觸發(fā) OOMhigh是軟限制超了會限速——分配變慢、回收加急但不會殺進(jìn)程。生產(chǎn)環(huán)境我建議兩個都設(shè)high設(shè)在max的 80%90%這樣能在真正 OOM 之前先有一個緩沖帶從監(jiān)控上能看到限速開始的信號有時間介入而不是直接被打死。7.2 透明大頁、NUMA 與性能觀測透明大頁THP是內(nèi)核自動把 4KB 頁合并成 2MB 頁的機(jī)制好處是 TLB 覆蓋范圍擴(kuò)大 512 倍、頁表層級減少、缺頁次數(shù)大幅下降。對內(nèi)存密集型應(yīng)用大數(shù)組遍歷、數(shù)據(jù)庫緩存加速效果明顯5%15% 的性能提升很常見。但 THP 有個著名的副作用khugepaged內(nèi)核線程后臺做頁合并時會持鎖導(dǎo)致某些延遲敏感型應(yīng)用出現(xiàn)幾十毫秒的抖動。所以現(xiàn)在的主流建議是數(shù)據(jù)庫、Redis、低延遲交易類服務(wù)用madvise模式echo madvise /sys/kernel/mm/transparent_hugepage/enabled讓應(yīng)用自己決定哪塊內(nèi)存用大頁一般業(yè)務(wù)用always沒問題。查看大頁使用情況$ cat /sys/kernel/mm/transparent_hugepage/enabled always [madvise] never $ grep -i huge /proc/meminfo AnonHugePages: 512000 kB ShmemHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kBAnonHugePages表示已經(jīng)被 THP 覆蓋的匿名內(nèi)存量。如果這個值一直是 0說明 THP 沒生效可能被never關(guān)掉了。NUMA 是另一塊。雙路服務(wù)器上CPU 訪問本地節(jié)點(diǎn)的內(nèi)存比訪問遠(yuǎn)端節(jié)點(diǎn)快 30%50%。默認(rèn)策略是就近分配但一個進(jìn)程在 CPU 0 上啟動、之后被調(diào)度到 CPU 1它的內(nèi)存可能還留在節(jié)點(diǎn) 0于是所有訪問都變成跨節(jié)點(diǎn)。觀察方式是用numastat看numa_miss和numa_foreign計數(shù)。對內(nèi)存帶寬敏感的應(yīng)用可以用numactl --membind0 --cpunodebind0綁死在一個節(jié)點(diǎn)上代價是浪費(fèi)另一半資源。除非確認(rèn)跨節(jié)點(diǎn)訪問是瓶頸否則不要輕易綁 NUMA坑比收益多。觀測工具上除了前面提到的/proc系列和slabtop值得掌握的是 bcc 工具集里的幾個工具用途典型場景cachestat頁緩存命中率判斷文件讀是否走緩存cachetop按進(jìn)程統(tǒng)計緩存命中定位哪個進(jìn)程在 missmemleak分配棧采樣定位用戶態(tài)泄漏點(diǎn)kmem內(nèi)核分配跟蹤定位內(nèi)核態(tài)泄漏oomkill捕獲 OOM 事件事后追溯被殺進(jìn)程這些工具需要內(nèi)核 4.9 和 bcc 環(huán)境在容器里跑還需要--privileged或者掛載/sys/kernel/debug部署前先確認(rèn)權(quán)限。7.3 我踩過的兩個真實案例第一個案例是容器里的 Java 服務(wù)反復(fù) OOM?，F(xiàn)象是容器限制 4GB-Xmx設(shè)了 2.5GB按理說很寬裕但運(yùn)行幾小時后必被 OOM 殺。用smaps_rollup一看RSS 只有 3.2GB其中堆占用 2.4GB剩下的 800MB 分散在線程棧200 多個線程 × 1MB 200MB、元空間150MB、JIT 代碼緩存240MB、直接內(nèi)存100MB、還有 glibc arena 碎片100MB 左右。堆只占 RSS 的四分之三其余部分如果按-Xmx去規(guī)劃必然失手。最終的解法是把-Xmx降到 2GBMaxMetaspaceSize和ReservedCodeCacheSize顯式設(shè)上限MALLOC_ARENA_MAX2并給容器留出 20% 的余量。調(diào)整后穩(wěn)定運(yùn)行了大半年。第二個案例是頁緩存把監(jiān)控搞瘋了。一臺跑著日志聚合服務(wù)的機(jī)器free顯示 used 58GB總 64GB監(jiān)控告警連著響了三天值班同事一直以為是內(nèi)存泄漏反復(fù)重啟服務(wù)沒用。我接手后先看MemAvailable有 52GB再slabtop一切正常smaps_rollup看各進(jìn)程 RSS 加起來不到 6GB。剩下的全在Cached里——是日志服務(wù)的輸出文件以 200MB/s 的速度寫入頁緩存自然堆滿。問題根本不在內(nèi)存而在于監(jiān)控用的是used而不是available并且這臺機(jī)器的日志輪轉(zhuǎn)策略有問題寫入量和保留時間都過長。改掉監(jiān)控指標(biāo)、縮短日志保留窗口之后告警消失。這兩個案例的共同點(diǎn)是卷進(jìn)去的時候所有人都在討論一個錯誤的數(shù)字。前者用堆大小當(dāng) RSS后者用 used 當(dāng)可用內(nèi)存。回到第一節(jié)那句話——先把三個詞的邊界劃清楚后面每一步判斷才有依托。Linux 內(nèi)存管理這套機(jī)制設(shè)計得相當(dāng)自洽難的不是理解某個單點(diǎn)而是在模糊的現(xiàn)場把它和眼前這堆數(shù)字對應(yīng)上。多做幾次采樣、多留一份對照慢慢就形成直覺了。