一、問題
近期我們運維同事接到線上 LB(負載均衡)服務內存報警,運維同事反饋說 LB 集群有部分機器的內存使用率超過 80%,有的甚至超過 90%,而且內存使用率還再不停的增長。接到內存報警的消息,讓整個團隊都比較緊張,我們團隊負責的 LB 服務是零售、物流、科技等業務服務的流量入口,承接上萬個服務的流量轉發,一旦有故障影響業務服務比較多,必須馬上著手解決內存暴漲的問題。目前只是內存報警,暫時不影響業務,先將內存使用率 90% 以上的 LB 服務下線,防止內存過高導致 LB 服務崩潰,影響業務,運維同事密切關注相關的內存報警的消息。
二、排查過程
經過開發同學通過 cat /proc/meminfo 查看 Slab 的內核內存可能有泄漏。
$ cat /proc/meminfo MemTotal: 65922868 kB MemFree: 9001452 kB ... Slab: 39242216 kB SReclaimable: 38506072 kB SUnreclaim: 736144 kB ....
通過 slabtop 命令分析 slab 發現內核中 dentry 對象占比高,考慮到 dentry 對象跟文件有關,Linux 中一切皆可以為文件,這個可能跟 socket 文件有關,通過進一步排查發現 LB 服務上有個 curl 發送的 HTTPS 探測腳本,這個腳本存在 dentry 對象泄漏,并且在 curl 論壇上找到一篇文章確認了這個問題,這個文章說明了 curl-7.19.7 版本在發送 HTTPS 請求時,curl 依賴的 NSS 庫存在 dentry 泄漏的 bug,我查看一下我們 curl 版本就是 7.19.7,問題終于真相大白了!!!
$ curl -V curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz $ rpm -aq|grep nss- nss-util-3.16.1-3.el6.x86_64 nss-sysinit-3.16.1-14.el6.x86_64 nss-softokn-freebl-3.14.3-17.el6.x86_64 nss-softokn-3.14.3-17.el6.x86_64 nss-3.16.1-14.el6.x86_64 nss-tools-3.16.1-14.el6.x86_64
文章中介紹可以設置環境變量 NSS_SDB_USE_CACHE 修復這個 bug,我們驗證通過了這個解決方案。
三、解決方案
1、目前先將探測腳本停止,在業務流量低峰時將內存使用率超過 90% 的服務先通過 drop_caches 清理一下緩存。
2、等大促過后,探測腳本中設置環境變量 NSS_SDB_USE_CACHE,徹底修復這個問題。
四、復盤和總結
這次內存暴漲的問題根本原因是 curl-7.19.7 依賴的 NSS 庫存在 dentry 泄漏的 bug 導致的,探測腳本只是將這個問題暴露出來。這次問題由 Linux 內存泄漏引發的問題,因此以點帶面再次系統學習一下 Linux 內存管理的知識非常有必要,對我們以后排查內存暴漲的問題非常有幫助。
1)Linux 內存尋址
Linux 內核主要通過虛擬內存管理進程的地址空間,內核進程和用戶進程都只會分配虛擬內存,不會分配物理內存,通過內存尋址將虛擬內存與物理內存做映射。Linux 內核中有三種地址,
a、邏輯地址,每個邏輯地址都由一段 (segment) 和偏移量 (offset) 組成,偏移量指明了從段開始的地方到實際地址之間的距離。
b、線性地址,又稱虛擬地址,是一個 32 個無符號整數,32 位機器內存高達 4GB,通常用十六進制數字表示,Linux 進程的內存一般說的都是這個內存。
c、物理地址,用于內存芯片級內存單元尋址。它們與從 CPU 的地址引腳發送到內存總線上的電信號對應。
Linux 中的內存控制單元 (MMU) 通過一種稱為分段單元 (segmentation unit) 的硬件電路把一個邏輯地址轉換成線性地址,接著,第二個稱為分頁單元 (paging unit) 的硬件電路把線性地址轉換成一個物理地址。
2)Linux 分頁機制
分頁單元把線性地址轉換成物理地址。線性地址被分成以固定長度為單位的組,稱為頁(page)。頁內部連續的線性地址被映射到連續的物理地址中。一般 "頁" 既指一組線性地址,又指包含這組地址中的數據。分頁單元把所有的 RAM 分成固定長度的頁框(page frame),也成物理頁。每一頁框包含一個頁 (page),也就是說一個頁框的長度與一個頁的長度一致。
頁框是主存的一部分,因此也是一個存儲區域。區分一頁和一個頁框是很重要的,前者只是一個數據塊,可以存放任何頁框或者磁盤中。把線性地址映射到物理地址的數據結構稱為頁表(page table)。頁表存放在主存中,并在啟用分頁單元之前必須有內核對頁表進行適當的初始化。 x86_64 的 Linux 內核采用 4 級分頁模型,一般一頁 4K,4 種頁表:
a、頁全局目錄
b、頁上級目錄
c、頁中間目錄
d、頁表
頁全局目錄包含若干頁上級目錄,頁上級目錄又依次包含若干頁中間目錄的地址,而頁中間目錄又包含若干頁表的地址。每個頁表項指向一個頁框。線性地址被分成 5 部分。
3)NUMA 架構
隨著 CPU 進入多核時代,多核 CPU 通過一條數據總線訪問內存延遲很大,因此NUMA架構應運而生,NUMA 架構全稱為非一致性內存架構 (Non Uniform Memory Architecture),系統的物理內存被劃分為幾個節點 (node),每個 node 綁定不同的 CPU 核,本地 CPU 核直接訪問本地內存 node 節點延遲最小。
可以通過lscpu 命令查看 NUMA 與 CPU 核的關系。
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 2 Core(s) per socket: 8 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 62 Stepping: 4 CPU MHz: 2001.000 BogoMIPS: 3999.43 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 20480K NUMA node0 CPU(s): 0-7,16-23 #這些核綁定在numa 0 NUMA node1 CPU(s): 8-15,24-31 #這些核綁定在numa 1
4)伙伴關系算法
Linux 內核通過著名伙伴關系算法為分配一組連續的頁框而建立一種健壯、穩定的內存分配策略,是內核中一種內存分配器,并解決了內存管理外碎片的問題,外碎片是指頻繁地請求和釋放不同大小的一組連續頁框,必然導致在已分配的頁框的塊分散了許多小塊的空閑頁框。
5)Slab 機制
slab機制的核心思想是以對象的觀點來管理內存,主要是為了解決內部碎片,內部碎片是由于采用固定大小的內存分區,即以固定的大小塊為單位來分配,采用這種方法,進程所分配的內存可能會比所需要的大,這多余的部分便是內部碎片。slab 也是內核中一種內存分配器,slab 分配器基于對象進行管理的,所謂的對象就是內核中的數據結構(例如:task_struct,file_struct 等)。
相同類型的對象歸為一類,每當要申請這樣一個對象時,slab 分配器就從一個 slab 列表中分配一個這樣大小的單元出去,而當要釋放時,將其重新保存在該列表中,而不是直接返回給伙伴系統,從而避免內部碎片。上面中說到的 dentry 對象就是通過 slab 分配器分配的一種對象。
slab 和伙伴系統是上下級的調用關系,伙伴關系按照頁管理內存,slab 按照字節管理,slab 先從伙伴系統獲取數個頁的內存,然后切成分成固定的小塊(稱為 object),然后再按照聲明的對象數據結構分配對象。
6)進程內存分布
所有進程都必須占用一定數量的內存,這些內存用來存放從磁盤載入的程序代碼,或存放來自用戶輸入的數據等。內存可以提前靜態分配和統一回收,也可以按需動態分配和回收。對于普通進程對應的內存空間包含 5 種不同的數據區:
a、代碼段 (text):程序代碼在內存中的映射,存放函數體的二進制代碼,通常用于存放程序執行代碼 (即 CPU 執行的機器指令)。
b、數據段 (data):存放程序中已初始化且初值不為 0 的全局變量和靜態局部變量。數據段屬于靜態內存分配 (靜態存儲區),可讀可寫。
c、BSS 段 (bss):未初始化的全局變量和靜態局部變量。
d、堆 (heap):動態分配的內存段,大小不固定,可動態擴張 (malloc 等函數分配內存),或動態縮減 (free 等函數釋放)。
e、棧 (stack):存放臨時創建的局部變量。
Linux 內核是操作系統中優先級最高的,內核函數申請內存必須及時分配適當的內存,用戶態進程申請內存被認為是不緊迫的,內核盡量推遲給用戶態的進程動態分配內存。
a、請求調頁,推遲到進程要訪問的頁不在 RAM 中時為止,引發一個缺頁異常。
b、寫時復制 (COW),父、子進程共享頁框而不是復制頁框,但是共享頁框不能被修改,只有當父 / 子進程試圖改寫共享頁框時,內核才將共享頁框復制一個新的頁框并標記為可寫。
7)Linux 內存檢測工具
a、free 命令可以監控系統內存
$ free -h total used free shared buff/cache available Mem: 31Gi 13Gi 8.0Gi 747Mi 10Gi 16Gi Swap: 2.0Gi 321Mi 1.7Gi
b、top 命令查看系統內存以及進程內存
?VIRTVirtual Memory Size (KiB):進程使用的所有虛擬內存,包括代碼(code)、數據(data)、共享庫(shared libraries),以及被換出(swap out)到交換區和映射了(map)但尚未使用(未載入實體內存)的部分。
?RESResident Memory Size (KiB):進程所占用的所有實體內存(physical memory),不包括被換出到交換區的部分。
?SHRShared Memory Size (KiB):進程可讀的全部共享內存,并非所有部分都包含在RES中。它反映了可能被其他進程共享的內存部分。
c、smaps 文件
cat /proc/$pid/smaps查看某進程虛擬內存空間的分布情況
0082f000-00852000 rw-p 0022f000 08:05 4326085 /usr/bin/nginx/sbin/nginx Size: 140 kB Rss: 140 kB Pss: 78 kB Shared_Clean: 56 kB Shared_Dirty: 68 kB Private_Clean: 4 kB Private_Dirty: 12 kB Referenced: 120 kB Anonymous: 80 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kBd、vmstat vmstat是 Virtual Meomory Statistics(虛擬內存統計)的縮寫,可實時動態監視操作系統的虛擬內存、進程、CPU 活動。
## 每秒統計3次 $ vmstat13 procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 000233483840758304207955960001000010000 000233483936758304207955960000105215690010000 00023348392075830420795596000096615580010000
e、meminfo 文件
Linux 系統中/proc/meminfo這個文件用來記錄了系統內存使用的詳細情況。
$ cat /proc/meminfo MemTotal: 8052444 kB MemFree: 2754588 kB MemAvailable: 3934252 kB Buffers: 137128 kB Cached: 1948128 kB SwapCached: 0 kB Active: 3650920 kB Inactive: 1343420 kB Active(anon): 2913304 kB Inactive(anon): 727808 kB Active(file): 737616 kB Inactive(file): 615612 kB Unevictable: 196 kB Mlocked: 196 kB SwapTotal: 8265724 kB SwapFree: 8265724 kB Dirty: 104 kB Writeback: 0 kB AnonPages: 2909332 kB Mapped: 815524 kB Shmem: 732032 kB Slab: 153096 kB SReclaimable: 99684 kB SUnreclaim: 53412 kB KernelStack: 14288 kB PageTables: 62192 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 12291944 kB Committed_AS: 11398920 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 1380352 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 201472 kB DirectMap2M: 5967872 kB DirectMap1G: 3145728 kB
審核編輯:劉清
-
Linux
+關注
關注
87文章
11232瀏覽量
208961 -
內存
+關注
關注
8文章
3004瀏覽量
73900 -
LINUX內核
+關注
關注
1文章
316瀏覽量
21619 -
MMU
+關注
關注
0文章
91瀏覽量
18268 -
NSS
+關注
關注
0文章
5瀏覽量
6371
原文標題:Linux內存泄露案例分析和內存管理分享
文章出處:【微信號:OSC開源社區,微信公眾號:OSC開源社區】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論