Linux性能優化實戰學習筆記：第十五講

1、內存映射

內存管理也是操做系統最核心的功能之一，內存主要用來存儲系統和應用程序的指令、數據、緩存等

一、咱們通說的內存指的是物理內存仍是虛擬內存？

咱們一般說的內存容量，其實這指的是物理內存，物理內存也稱爲主存，大多數計算機用的主存都是動態隨機訪問內存（DRAM）。只有內核才能夠直接訪問物理內存。

那麼，進程要訪問內存時，該怎麼辦呢？

二、進程是如何訪問內存的？

Linux 內核給每一個進程都提供了一個獨立的虛擬地址空間，而且這個地址空間是連續的。這樣，進程就能夠很方便地訪問內存，更確切地說是訪問虛擬內存

三、虛擬內存的內核空間和用戶空間分佈圖

四、進程是如何訪問內核空間內存的？

進程在用戶態時，只能訪問用戶內存；只有進入內核態後，才能夠訪問內核空間內存，雖然每一個進程的地址空間都包含了內核空間，但這些內核空間，其實關聯的都是想同的物理內存

這樣、進程切換到內核態後，就能夠很方便地訪問內核空間內存

五、並非全部的虛擬機內存都會分配物理內存

既然每一個進程都有一個這麼大的地址空間，那麼全部進程的虛擬內存加起來，天然要比實際的物理內存大得多

因此並非全部的虛擬機內存都會分配物理內存，只有那些實際使用的虛擬機內存才分配物理內存，而且分配後的物理內存，是經過內存映射來管理的

六、什麼是內存映射？

內存映射，其實就是將虛擬內存地址映射到物理內存地址，爲了完成內存映射，內核爲每一個進程都維護了一張頁表，
記錄虛擬地址與物理地址的映射關係，以下圖所示：

頁表實際上存儲在 CPU 的內存管理單元 MMU 中，這樣，正常狀況下，處理器就能夠直接經過硬件，找出要訪問的內存

七、進程訪問的虛擬地址在頁表中查不到，怎麼辦？

當進程訪問的虛擬地址在頁表中查不到時，系統會產生一個缺頁異常，進入內核空間分配物理內存、更新進程頁表，最後再返回用戶空間、恢復進程運行

八、什麼是TLB？TLB的做用是什麼

TLB 其實就是 MMU 中頁表的高速緩存，因爲進程的虛擬地址空間是獨立的，而 TLB 的訪問速度又比MMU 快得多，

因此，經過減小進程的上下文切換，減小 TLB 的刷新次數，就能夠提升 TLB 緩存的使用率，進而提升 CPU 的內存訪問性能。

九、MMU 是以什麼爲單位來管理內存？

不過要注意，MMU 並不以字節爲單位來管理內存，而是規定了一個內存映射的最小單位，也就是頁，一般是 4 KB大小，

這樣，每一次內存映射，都須要關聯 4 KB 或者 4KB 整數倍的內存空間

十、如何減小頁表的項數

頁的大小隻有 4 KB ，致使的另外一個問題就是，整個頁表會變得很是大。比方說，僅 32 位系統就須要 100 多萬個頁表項（4GB/4KB），才能夠實現整個地址空間的映射。

爲了解決頁表項過多的問題，Linux 提供了兩種機制，也就是多級頁表和大頁（HugePage）。

十一、多級頁

多級頁表就是把內存分紅區塊來管理，將原來的映射關係改爲區塊索引和區塊內的偏移。因爲虛擬內存空間一般只用了不多一部分，

那麼多級頁表就只保存這些使用中的區塊，這樣就能夠大大地減小頁表的項數

Linux 用的正是四級頁表來管理內存頁,以下圖所示，虛擬地址被分爲 5 個部分，前 4 個表項用於選擇頁，而最後一個索引表示頁內偏移。

十二、大頁

再看大頁，顧名思義，就是比普通頁更大的內存塊，常見的大小有 2MB 和 1GB。大頁一般用在使用大量內存的的進程上，好比 Oracle、DPDK 等

經過這些機制，在頁表的映射下，進程就能夠經過虛擬地址來訪問物理內存了。那麼具體到一個 Linux 進程中，這些內存又是怎麼使用的呢

2、虛擬內存空間分佈

一、虛擬內存空間分佈圖

經過這張圖你能夠看到，用戶空間內存，從低到高分別是五種不一樣的的內存段

二、虛擬內存空間分佈詳解

一、在這五個內存段中，堆和文件映射段的內存是動態分配的，好比說，使用 C 標準庫的 malloc() 或者mmap() ，就能夠分別在堆和文件映射段動態分配內存

二、其實 64 位系統的內存分佈也相似，只不過內存空間要大得多，那麼，更重要的問題來了，內存到底是怎麼分配的呢？

3、內存分配與回收

malloc() 是 C 標準庫提供的內存分配函數，對應到系統調用上，有兩種實現方式，即 brk() 和 mmap()。

一、內存分配

都只在首次訪問時才分配，也就是經過缺頁異常進入內核中，再由內內核來分配內存。

一、如何減小內存碎片？

總體來講，Linux 使用夥伴系統來管理內存分配。前面咱們提到過，這些內存在 MMU 中以頁爲單位進行管理，夥伴系統也一系統也同樣，以頁爲單位來管理內存，而且會經過相鄰頁的合併，
減小內存碎片化（好比 brk 方式形成的內存碎片）。

二、比頁更小的內存（不到 1K ），該怎麼分配內存呢？

實際系統運行中，確實有大量比頁還小的對象若是爲它們也分配單獨的頁，那就太浪費內存了。因此，在用戶空間，malloc 經過 brk() 分配的內存，在釋放時並不當即歸還系統，

而是緩存起來重複利用。在內核空間，Linux 則經過 slab 分配器來管理小內存。你能夠把slab 當作構建在夥伴系統上的一個緩存，主要做用就是分配並分配並釋放內核中的小對象。

二、內存回收

對內存來講，若是隻分配而不釋放，就會形成內存泄漏，甚至會耗盡系統內存。因此，在應用程序用完內存後，還須要調用free() 或 unmap() ，來釋放這些不用的內存。

固然，系統也不會任由某個進程用完全部內存，在發現內存緊張時，系統就會經過一系列機制來回收內存，好比下面下面這三種方式：

 

第三種方式提到的 OOM（Out of Memory），實際上是內核的一種保護機制它監控進程的內存使用狀況，而且使用 oom_score 爲每一個進程的內存使用狀況進行評分：

一個進程消耗的內存越大，oom_score 就越大；

一個進程運行佔用的 CPU 越多，oom_score 就越小

這樣，進程的 oom_score 越大，表明消耗的內存越多，也就越容易被 OOM 殺死，從而能夠更好保護系統。

固然，爲了實際工做的須要，管理員能夠經過 /proc 文件系統，手動設置進程的 oom_adj ，從而調整進程的 oom_score。

oom_adj 的範圍是 [-17, 15]，數值越大，表示進程越容易被 OOM 殺死；數值越小，表示進程越不容易被 OOM 殺死，其中 -17 表示禁止 OOM。

好比用下面的命令，你就能夠把 sshd 進程的調小爲 -16，這樣， sshd 進程就不容易被 OOM 殺死

echo -16 > /proc/$(pidof sshd)/oom_adj

4、如何查看內存使用狀況

一、free圖解

[root@api ~]# free
total used free shared buff/cache available
Mem: 8010968 935180 5968260 16668 1107528 6835728
Swap: 4194300 0 4194300

這裏尤爲注意一下，最後一列的可用內存 available，available 不只包含未使用內存，還包括了可回收的緩存，因此通常會比未使用內存更大。

不過，並非全部緩存均可以回收，因此通常會比未使用內存更大

 二、top圖解

top - 11:52:35 up 16 days, 55 min, 1 user, load average: 0.00, 0.01, 0.05
Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 14.7/8010968 [||||||||||||||| ]
KiB Swap: 0.0/4194300 [ ]

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 41348 3580 2332 S 0.0 0.0 0:36.59 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0

 

VIRT 是進程虛擬內存的大小：只要是進程申請過的內存，即使尚未真正分配物理內存，也會計算在內。

RES 是常駐內存的大小：也就是進程實際使用的物理內存大小，但不包括 Swap 和共享內存。

SHR 是共享內存的大小：好比與其餘進程共同使用的共享內存、加載的動態連接庫以及程序的代碼段等。

%MEM 是進程使用物理內存佔系統總內存的百分比。

三、須要注意兩點

第一：虛擬內存一般並不會所有分配物理內存。從上面的輸出，你能夠發現每一個進程的虛擬內存都比常駐內存大得多。

第二：共享內存 SHR 並不必定是共享的，比方說，程序的代碼、非共享的動態連接庫，也都算在 SHR 裏。固然，

SHR 也包括了進程間真正共享的內存。因此在計算多個進程的內存使用時，不要把全部進程的 SHR 直接相加得出結果。