Linux的內存中Swap和Cache以及Buffer的介紹是怎樣的

Linux的內存中Swap和Cache以及Buffer的介紹是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

•  total：總內存大小。

•  used：已經使用的內存大小（這里面包含cached和buffers和shared部分）。

•  free：空閑的內存大小。

•  shared：進程間共享內存（一般不會用，可以忽略）。

•  buffers：內存中寫完的東西緩存起來，這樣快速響應請求，后面數據再定期刷到磁盤上。

•  cached：內存中讀完緩存起來內容占的大小（這部分是為了下次查詢時快速返回）。

-/+ buffers/cache看做兩部分：

•  -buffers/cache：正在使用的內存大小（注意不是used部分，因為buffers和cached并不是正在使用的，組織和人民需要是它們是可以釋放的），其值=used-buffers-cached。

•  +buffers/cache：可用的內存大小（同理也不是free表示的部分），其值=free+buffers+cached。

Swap：硬盤上交換分區的使用大小。

設計的目的就是當上面提到的+buffers/cache表示的可用內存都已使用完，新的讀寫請求過來后，會把內存中的部分數據寫入磁盤，從而把磁盤的部分空間當做虛擬內存來使用。

2、Buffer和Cache介紹

Cache（緩存），為了調高CPU和內存之間數據交換而設計，Buffer（緩沖）為了提高內存和硬盤（或其他I/O設備的數據交換而設計）。

Cache主要是針對讀操作設計的，不過Cache概念可能容易混淆，我理解為CPU本身就有Cache，包括一級緩存、二級緩存、三級緩存，我們知道CPU所有的指令操作對接的都是內存，而CPU的處理能力遠高于內存速度，所以為了不讓CPU資源閑置，Intel等公司在CPU內部集成了一些Cache，但畢竟不能放太多電路在里面，所以這部分Cache并不是很大，主要是用來存放一些常用的指令和常用數據，真正大部分Cache的數據應該是占用內存的空間來緩存請求過的數據，即上面的Cached部分（這部分純屬個人理解，正確與否有待考證）。

Buffer主要是針對寫操作設計的，更細的說是針對內存和硬盤之間的寫操作來設計的，目的是將寫的操作集中起來進行，減少磁盤碎片和硬盤反復尋址過程，提高性能。

在Linux系統內部有一個守護進程會定期清空Buffer中的內容，將其寫入硬盤內，當手動執行sync命令時也會觸發上述操作。

3、常見癥狀

癥狀一：在Linux中頻繁存取文件，物理內存很快用光，而cached一直在增長。

解釋：Linux會對每次請求過的數據緩存在cache里，好處就是CPU的處理速度遠遠高于內存，所以在CPU和內存通訊的時候可以快速從cache中命中結果返回。

癥狀二：Swap被占用。

解釋：內存可能不夠了，才會占Swap，所以Swap可以作為服務器監控的一項指標，引起注意。

4、手動清理Swap和buffers/cache

(1) 清理Swap

swapoff -a && swapon -a

操作說明：如果已經使用了Swap，且當前清空下+buffers/cache還有空間，在執行  swapoff -a操作時，會觸發把Swap中的內容交換到內存中，數據不會丟失。

(2) 清理buffers/cache:

sync; sync; sync;&& echo 3 >/proc/sys/vm/drop_caches  sleep 2  echo 0 > /proc/sys/vm/drop_caches

操作說明：

sync-->將緩存的內從寫回到硬盤中；  echo 3 >/proc/sys/vm/drop_caches-->修改drop_caches的值為3，默認為0，改為3系統會清理緩存的內容；  sleep 2 --> 等一下，防止上一步沒執行完；  echo 0 >/proc/sys/vm/drop_caches --> 改回默認值

5、總結

通過上面的分析可以知道，當空閑物理內存不多時，不一定表示系統運行狀態很差，因為內存的cache及buffer部分可以隨時被重用，在某種意義上，這兩部分內存也可以看作是額外的空閑內存。

swap如果被頻繁調用，bi，bo長時間不為0，則才是內存資源是否緊張的依據。通過free看資源時，實際主要關注-/+ buffers/cache的值就可以知道內存到底夠不夠了。

看完上述內容，你們掌握Linux的內存中Swap和Cache以及Buffer的介紹是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！