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