[CentOS5] 解決yum 停止支援的問題

資料來源:http://n.sfs.tw/mymedia/index/10327

這近要用yum更新套件時，發現不能更新。

OS

# lsb_release -a
LSB Version:    :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 5.8 (Final)
Release:        5.8  <==太舊了
Codename:       Final

# yum install package
Loaded plugins: fastestmirror
Determining fastest mirrors
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
 Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/cache/yum/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base

我以為是我的yum 壞掉了，到repository去看才知道是停止支援。該版本的目錄還在，只是沒檔案，留了一個字條：

This directory (and version of CentOS) is depreciated. CentOS-5 is now past EOL You can get the last released version of centos 5.11 here: http://vault.centos.org/5.11/ Please NOTE: this is not being maintained for security since moving to Vault. It will have security issues, you should upgrade to a new version instead.

好的，至少還有「遺跡」可以用。

修改

# vi /etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
baseurl=http://vault.centos.org/5.8/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
baseurl=http://vault.centos.org/5.8/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
baseurl=http://vault.centos.org/5.8/extras/$basearch/

gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

把原本的註解或刪掉，加上上面黃色的。

勉強能用

[相關連結]

http://blog.sina.com.cn/s/blog_541a3cf10101h245.html

Software Raid: 分散式檔案系統

分散式檔案系統

歷史
第一個檔案伺服器在1970年代被發展出來。在1976年迪吉多公司設計出File Access Listener（FAL）做為第二代DECnet的一部分。
這個系統實作了Data Access Protocol，是第一個被廣為使用的網路檔案系統。在1985年昇陽電腦建立了網路檔案系統（Network File System，NFS），
這是第一個基於網際協定（Internet Protocol）而被廣泛使用的網路檔案系統。在相關技術的演進過程中，
其他值得一提的網路檔案系統還有安德魯檔案系統（AFS）、Apple Filing Protocol（AFP）、NetWare核心協定（NCP）、
和一般被稱為網路檔案分享系統（CIFS）的伺服器訊息區塊（Server Message Block，SMB）等。

相對於本機端的檔案系統而言，分散式檔案系統（英語：Distributed file system, DFS），或是網路檔案系統（英語：Network File System），
是一種允許檔案透過網路在多台主機上分享的檔案系統，可讓多機器上的多使用者分享檔案和儲存空間。
在這樣的檔案系統中，客戶端並非直接存取底層的資料儲存區段，而是透過網路，以特定的通訊協定和伺服器溝通。
藉由通訊協定的設計，可以讓客戶端和伺服器端都能根據存取控制清單或是授權，來限制對於檔案系統的存取。
相對地，在一個分享的磁碟檔案系統中，所有節點對資料儲存區段都有相同的存取權，在這樣的系統中，存取權限就必須由客戶端程式來控制。
分散式檔案系統可能包含的功能有：透通的資料複製與容錯。也就是說，即使系統中有一小部份的節點離線，整體來說系統仍然可以持續運作而不會有資料損失。
分散式檔案系統和分散式資料儲存的界線是模糊的，但一般來說，分散式檔案系統是被設計用在區域網路[1]，比較強調的是傳統檔案系統概念的延伸，並透過軟體方法來達成容錯。
而分散式資料儲存，則是泛指應用分散式運算技術的檔案和資料庫等提供資料儲存服務的系統。

資料來源: 維基百科，自由的百科全書

Redundant Arrays of Inexpensive Disks, RAID

磁碟陣列全名是『 Redundant Arrays of Inexpensive Disks, RAID 』，
英翻中的意思是：容錯式廉價磁碟陣列。 RAID 可以透過一個技術(軟體或硬體)，將多個較小的磁碟整合成為一個較大的磁碟裝置；
而這個較大的磁碟功能可不止是儲存而已，他還具有資料保護的功能呢。整個 RAID 由於選擇的等級 (level) 不同，而使得整合後的磁碟具有不同的功能，基本常見的 level 有這幾種(註1)：

RAID-0 (等量模式, stripe)：效能最佳
這種模式如果使用相同型號與容量的磁碟來組成時，達到儲存容量全部使用兩倍容量，讀取速度有機會兩倍，寫入速度1.5倍最高。

RAID-1 (映射模式, mirror)：完整備份
這種模式也是需要相同的磁碟容量的，最好是一模一樣的磁碟啦！如果是不同容量的磁碟組成 RAID-1 時，那麼總容量將以最小的那一顆磁碟為主！
這種模式主要是『讓同一份資料，完整的保存在兩顆磁碟上頭』。舉例來說，如果我有一個 100MB 的檔案，且我僅有兩顆磁碟組成 RAID-1 時， 那麼這兩顆磁碟將會同步寫入 100MB 到他們的儲存空間去。
因此，整體 RAID 的容量幾乎少了 50%。由於兩顆硬碟內容一模一樣，好像鏡子映照出來一樣， 所以我們也稱他為 mirror 模式囉～
由於兩顆磁碟內的資料一模一樣，所以任何一顆硬碟損毀時，你的資料還是可以完整的保留下來的！
所以我們可以說， RAID-1 最大的優點大概就在於資料的備份吧！不過由於磁碟容量有一半用在備份，因此總容量會是全部磁碟容量的一半而已。
雖然 RAID-1 的寫入效能不佳，不過讀取的效能則還可以啦！這是因為資料有兩份在不同的磁碟上面，如果多個 processes 在讀取同一筆資料時， RAID 會自行取得最佳的讀取平衡。

RAID 5：效能與資料備份的均衡考量
RAID-5 至少需要三顆以上的磁碟才能夠組成這種類型的磁碟陣列。這種磁碟陣列的資料寫入有點類似 RAID-0 ， 不過每個循環的寫入過程中，在每顆磁碟還加入一個同位檢查資料 (Parity)，
這個資料會記錄其他磁碟的備份資料， 用於當有磁碟損毀時的救援。RAID-5 讀寫的情況有點像底下這樣：
在讀寫效能的比較上，讀取的效能還不賴！與 RAID-0 有的比！不過寫的效能就不見得能夠增加很多！ 這是因為要寫入 RAID 5 的資料還得要經過計算同位檢查碼 (parity) 的關係。
由於加上這個計算的動作， 所以寫入的效能與系統的硬體關係較大！尤其當使用軟體磁碟陣列時，同位檢查碼是透過 CPU 去計算而非專職的磁碟陣列卡， 因此效能方面還需要評估。

RAID 6：效能與資料備份的均衡考量,容錯提升容量減少!
另外，由於 RAID 5 僅能支援一顆磁碟的損毀，因此近來還有發展出另外一種等級，就是 RAID 6 ，
這個 RAID 6 則使用兩顆磁碟的容量作為 parity 的儲存，因此整體的磁碟容量就會少兩顆，但是允許出錯的磁碟數量就可以達到兩顆了！
也就是在 RAID 6 的情況下，同時兩顆磁碟損毀時，資料還是可以救回來！

Spare Disk：預備磁碟的功能：
當磁碟陣列的磁碟損毀時，就得要將壞掉的磁碟拔除，然後換一顆新的磁碟。換成新磁碟並且順利啟動磁碟陣列後，
磁碟陣列就會開始主動的重建 (rebuild) 原本壞掉的那顆磁碟資料到新的磁碟上！然後你磁碟陣列上面的資料就復原了！
這就是磁碟陣列的優點。不過，我們還是得要動手拔插硬碟，此時通常得要關機才能這麼做。
為了讓系統可以即時的在壞掉硬碟時主動的重建，因此就需要預備磁碟 (spare disk) 的輔助。
所謂的 spare disk 就是一顆或多顆沒有包含在原本磁碟陣列等級中的磁碟，這顆磁碟平時並不會被磁碟陣列所使用，
當磁碟陣列有任何磁碟損毀時，則這顆 spare disk 會被主動的拉進磁碟陣列中，並將壞掉的那顆硬碟移出磁碟陣列！ 然後立即重建資料系統。
如此你的系統則可以永保安康啊！若你的磁碟陣列有支援熱拔插那就更完美了！ 直接將壞掉的那顆磁碟拔除換一顆新的，再將那顆新的設定成為 spare disk ，就完成了！

磁碟陣列的優點
說的口沫橫飛，重點在哪裡呢？其實你的系統如果需要磁碟陣列的話，其實重點在於：

資料安全與可靠性：指的並非資訊安全，而是當硬體 (指磁碟) 損毀時，資料是否還能夠安全的救援或使用之意；
讀寫效能：例如 RAID 0 可以加強讀寫效能，讓你的系統 I/O 部分得以改善；
容量：可以讓多顆磁碟組合起來，故單一檔案系統可以有相當大的容量。
尤其資料的可靠性與完整性更是使用 RAID 的考量重點！畢竟硬體壞掉換掉就好了，軟體資料損毀那可不是鬧著玩的！ 所以企業界為何需要大量的 RAID 來做為檔案系統的硬體基準，現在您有點瞭解了吧？

為何磁碟陣列又分為硬體與軟體呢？所謂的硬體磁碟陣列 (hardware RAID) 是透過磁碟陣列卡來達成陣列的目的。
磁碟陣列卡上面有一塊專門的晶片在處理 RAID 的任務，因此在效能方面會比較好。在很多任務 (例如 RAID 5 的同位檢查碼計算) 磁碟陣列並不會重複消耗原本系統的 I/O 匯流排，
理論上效能會較佳。此外目前一般的中高階磁碟陣列卡都支援熱拔插， 亦即在不關機的情況下抽換損壞的磁碟，對於系統的復原與資料的可靠性方面非常的好用。
不過一塊好的磁碟陣列卡動不動就上萬元台幣，便宜的在主機板上面『附贈』的磁碟陣列功能可能又不支援某些高階功能，
由於磁碟陣列有很多優秀的功能，然而硬體磁碟陣列卡偏偏又貴的很～因此就有發展出利用軟體來模擬磁碟陣列的功能， 這就是所謂的軟體磁碟陣列 (software RAID)。
軟體磁碟陣列主要是透過軟體來模擬陣列的任務， 因此會損耗較多的系統資源，比如說 CPU 的運算與 I/O 匯流排的資源等。
不過目前我們的個人電腦實在已經非常快速了， 因此以前的速度限制現在已經不存在！所以我們可以來玩一玩軟體磁碟陣列！

參考來源:  鳥哥 linux 私房菜!

Software Raid: ZFS

ZFS:

歷史
ZFS的設計與開發由Sun公司的Jeff Bonwick所領導的一支團隊完成。
最早宣布於2004年9月14日，[1]於2005年10月31日併入了Solaris開發的主幹原始碼。
[2]並在2005年11月16日作為OpenSolaris build 27的一部分釋出。Sun在OpenSolaris社群開張1年後的2006年六月，將ZFS整合進了Solaris 10 6/06版本更新。[3]
ZFS的命名來源發想於"Zettabyte File System"的首字母縮寫。[4]但ZFS本身並不具備任何的縮寫意涵，只是作者想闡述做為一個具備高擴充容量檔案系統且還有支援許多延伸功能的一個產品。

儲存池
不同於傳統檔案系統需要駐留於單獨裝置或者需要一個卷管理系統去使用一個以上的裝置，
ZFS建立在虛擬的，被稱為「zpools」的儲存池之上（儲存池最早在AdvFS實現[5]，並且加到後來的Btrfs）。
每個儲存池由若干虛擬裝置（virtual devices，vdevs）組成。這些虛擬裝置可以是原始磁碟，也可能是一個RAID1鏡像裝置，或是非標準RAID等級的多磁碟組。
於是zpool上的檔案系統可以使用這些虛擬裝置的總儲存容量。

可以使用磁碟限額以及設定磁碟預留空間來限制儲存池中單個檔案系統所占用的空間。

ZFS 是一個從本質上與眾不同的檔案系統，由於它並非只是一個檔案系統，
ZFS 結合了檔案系統及磁碟區管理程式，讓額外的儲存裝置可以即時的加入到系統並可讓既有的檔案系統立即使用這些在儲存池中空間。
透過結合傳統區分為二的兩個角色，ZFS 能夠克服以往 RAID 磁碟群組無法擴充的限制。每個在儲存池頂層的裝置稱作 vdev，其可以是一個簡單的磁碟或是一個 RAID 如鏡像或 RAID-Z 陣列。

ZFS 的檔案系統 (稱作 資料集 (Dataset)) 每一個資料集均可存取整個存池所共通的可用空間，隨著使用儲存池來配置空間區塊，儲存池能給每個檔案系統使用的可用空間就會減少，這個方法可以避免擴大分割區會使的可用空間分散分割區之間的常見問題。

Software Raid: Gluster FS

Gluster FS:

歷史
Gluster 在 2011 年被 Red Hat 所購買並且成為產品線的一部份，因為分散式檔案系統可以解決傳統上所有檔案存放於單一主機時不易擴充的問題，並且可以增進檔案存取的速度。
Gluster 的導入解決了資料量增加，空間不易同時擴充的問題，也解決所有流量儲存於同一節點時資源消耗的問題。
在檔案可靠性方面，Gluster 提供了 Replicated 模式將同一份資料同時寫入兩個節點，所以就算其中一組異常其檔案存取仍可以正常運作，而且資料不會不見。

Gluster 是一個分散式的檔案系統，擁有下列明顯的特性：
1.可以線上擴增使用空間。
2.線上修改架構。
3.不需要 metadata 伺服器。

4.線上增加、刪除、取代儲存庫成員。

可以線上擴增使用空間
通常在更換硬體設備時需要將伺服器關機然後安裝相關硬體後再上線，在關機的這段時間裡，客戶端無法存取資料與操作檔案。
Gluster 可以彈性擴充增加伺服器節點，將新的節點加入到原本的 Gluster 儲存庫中，使用者不用擔心檔案操作的問題。

線上修改架構
Gluster 支援了分散式架構、複本架構與分散複本架構，在現行的環境中可以將這些架構任意的更改而且不用中斷服務，客戶端仍可以正常的操作檔案。

Distributed 分散式架構
分散式架構是 Gluster 預設的架構模式，建立完成之後客戶端會將檔案分散到不同的節點存放，如此一來可以增加檔案的存取速度。

Replication 複本架構
Gluster 允許的複本（Replication）機制設定後，同一時間將檔案寫入到兩個節點，製作複本是由客戶端進行，當檔案在寫入或修改時會同時操作兩個節點資料。
當複本架構中的任一節點故障時，整個存儲空間不會損壞，Gluster 會自動從所對應中的節點取得檔案。

Distributed-Replication 分散複本架構
分散複本架構同時擁有分散式與複本的優點(但是也需要更多節點），您可以在一個複本架構中增加多個分散式節點，如此資料會分散到更多的節點中，可以增加更多的讀取效能。

不需要 metadata 伺服器
Gluster 使用了 Elastic Hash Algorithm 演算法將檔案與目錄算出獨一的結果，此一結果能夠決定檔案是存放在哪一個節點上。
當客戶端要存取檔案的時候不就可以直接到檔案所存放的節點中存取，達到平行存取的機制。
因為每一個檔案都可以被計算出其真正的儲存位置，所以不需要獨立的 metadata 用來儲存檔案與伺服器位置的關係對應，這樣可以減少 metadata 伺服器效能與損毀的問題。

線上增加、刪除、取代儲存池成員
以往的儲存設備在空間不足時用時，擴充方式通常是使用一個更大的儲存空間取代，在進行空間儲存時必需中斷現有的儲存服務，
使用者無法存取儲存空間與檔案，在建立完成後還要面對一個長時間的等待－檔案複製與權限設定。
在 Gluster 儲存服務中，您可以很有彈性的增加空間，而且不用停機、不用將現有檔案重新複製到新的空間、不用重新設定檔案權限，使用者依然正常的使用者儲存服務而沒有任何的感覺。

新增節點空間
使用 Gluster 可以將新的節點空間加入已存在的儲存庫，客戶端不用異動任何檔案與資料。
新加入的空間馬上可以反應在客戶端的可用容量上並且開始使用。您不用擔心浪費即有還能使用的儲存設備，也可以增加檔案存取的效能。
在您新增節點空間後，可以使用內建的 rebalance 功能重新分配 Gluster 檔案配置的位置，重新分配完成之後也可以取得較佳的效態（不論是讀取或是寫入）。

節點取代
任何的伺服器都有故障的時候，就算您使用了最高階的儲存設備也是一樣。經由 Gluster 架構，您可以很容易的使用新節點伺服器取代舊有的設備，
所有的檔案同步作業會自動進行不必使用人工進行檔案複製，這樣不旦保有了檔案並且權限也會一併保留。

節點刪除
在大部份的情況之下都是新增容量而不是減少容量，但是 Gluster 提供了節點刪除的功能，刪除節點會減少可用空間，被刪除的節點伺服器可以重新分配應用。

在節點刪除的時候，Gluster 將所有的檔案進行重新分配（rebalance），將它們重新放置在沒有被刪除的節點伺服器上。

來源參考: http://www.l-penguin.idv.tw/book/Gluster-Storage_GitBook/index.html

Linux 指令!

** cifs 
sudo apt-get install cifs-utils
mount -t cifs //10.10.8.152/root/Vicom /VersaPLX -o username=root,password=accusys,vers=1.0

linux I/O優化設定參數!

查看關於 buffers cache 緩存的信息
cat /proc/meminfo  or free -wh

其中的Cached指用於pagecache的內存大小（diskcache-SwapCache）。
隨著寫入緩存頁，Dirty的值會增加。
一旦開始把緩存頁寫入硬盤,Writeback的值會增加直到寫入結束。

Linux用pdflush進程把數據從緩存頁寫入硬盤，查看有多少個pdflush進程
cat /proc/sys/vm/nr_pdflush_threads

pdflush的行為受/proc/sys/vm中的參數的控制
/proc/sys/vm/ dirty_writeback_centisecs (default 500 (0.01秒)): 
多長時間喚醒pdflush將緩存頁數據寫入硬盤。默認5秒喚醒2個（更多個）線程。
如果wrteback的時間長於dirty_writeback_centisecs的時間，可能會出問題。

pdflush的第一件事是讀取
/proc/sys/vm/dirty_expire_centiseconds (default 3000 (0.01秒))
緩存頁里數據的過期時間(舊數據)，在下一個週期內被寫入硬盤。默認30秒是一個很長的時間。

第二件事是判斷內存是否到了要寫入硬盤的限額，由參數決定：
/proc/sys/vm/dirty_background_ratio (default 10)
百分值，保留過期頁緩存（臟頁緩存）的最大值。是以MmeFree+Cached-Mapped的值為基準的

pdflush寫入硬盤看兩個參數：
1數據在頁緩存中是否超出30秒，如果是，標記為臟頁緩存;
2臟頁緩存是否達到工作內存的10%;

以下參數也會影響到pdflush
/proc /sys/vm/dirty_ratio (default 40)
總內存的最大百分比，系統所能擁有的最大臟頁緩存的總量。超過這個值，開啟pdflush寫入硬盤。
如果cache增長快於pdflush，那麼整個系統在40%的時候遇到I/O瓶頸，所有的I/O都要等待cache被pdflush進硬盤後才能重新開始。

對於有高度寫入操作的系統
dirty_background_ratio:主要調整參數。如果需要把緩存持續的而不是一下子大量的寫入硬盤，降低這個值。
dirty_ratio：第二調整參數。

Swapping參數
/proc/sys/vm/swappiness
默認，linux傾向於從物理內存映射到硬盤緩存，保持硬盤緩存盡可能大。未用的頁緩存會被放進swap區。
數值為0，將會避免使用swapping
100，將會盡量使用swapping
少用swapping會增加程序的響應速度；多用swapping將會提高系統的可用性。

如果有大量的寫操作，為避免I/O的長時間等待，可以設置：
$ echo 5 > /proc/sys/vm/dirty_background_ratio
$ echo 10 > /proc/sys/vm/dirty_ratio

文件系統數據緩衝需要頻繁的內存分配。加大保留內存的值能提升系統速度和穩定。小於8G的內存，保留內存為64M，大於8G的設置為256M
$ echo 65536 > /proc/sys/vm/min_free_kbytes


I/O調度器
cat /sys/block/[disk]/queue/scheduler 

調度算法
** noop deadline [cfq] 
    deadline: deadline算法保證對既定的IO請求以最小的延遲時間。
    cfq: 對每個進程維護一個IO隊列，各個進程發來的IO請求會被cfq以輪循方式處理，對每一個IO請求都是公平。適合離散讀的應用。
    noop: 對所有IO請求都用FIFO隊列形式處理。默認IO不會存在性能問題。

改變調度器
$ echo deadline > /sys/block/sdX/queue/scheduler
對於數據庫服務器，deadline算法是推薦的。

提高調度器請求隊列的
$ echo 4096 > /sys/block/sdX/queue/nr_requests

有大量的讀請求，默認的請求隊列應付不過來，可以提高這個值。缺點是要犧牲一定的內存。
為了增加連續讀取的吞吐量，可以增加預讀數據量。預讀的實際值是自適應的，所以使用一個較高的值，不會降低小型隨機存取的性能。
$ echo 4096 > /sys/block/sdX/queue/read_ahead_kb
如果LINUX判斷一個進程在順序讀取文件，那麼它會提前讀取進程所需文件的數據，放在緩存中。
 

服務器遇到磁盤寫活動高峰，導致請求處理延遲非常大（超過3秒）。
通過調整內核參數，將寫活動的高峰分佈成頻繁的多次寫，每次寫入的數據比較少。這樣可以把尖峰的寫操作削平成多次寫操作。
以這種方式執行的效率比較低，因為內核不太有機會組合寫操作。但對於繁忙的服務器，寫操作將更一致地進行，並將極大地改進交互式性能。
/proc/sys/vm/dirty_ratio
控製文件系統的寫緩衝區的大小，單位是百分比，表示佔系統內存的百分比，表示當寫緩衝使用到系統內存多少的時候，開始向磁盤寫出數據。
增大之會使用更多系統內存用於磁盤寫緩衝，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降低其數值。

/proc/sys/vm/dirty_background_ratio
控製文件系統的pdflush進程，在何時刷新磁盤。單位是百分比，表示系統內存的百分比，pdflush用於將內存中的內容和文件系統進行同步，
比如說,當一個文件在內存中進行修改,pdflush負責將它寫回硬盤.每當內存中的垃圾頁（dirty page）超過10%的時候,pdflush就會將這些頁面備份回硬盤.
增大之會使用更多系統內存用於磁盤寫緩衝，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降低其數值：

/proc/sys/vm/dirty_writeback_centisecs
控制內核的髒數據刷新進程pdflush的運行間隔。單位是1/100秒。缺省數值是500，也就是5秒。如果你的系統是持續地寫入動作，那麼實際上還是降低這個數值比較好，
這樣可以把尖峰的寫操作削平成多次寫操作。
如果你的系統是短期地尖峰式的寫操作，並且寫入數據不大（幾十M/次）且內存有比較多富裕，那麼應該增大此數值。
該參數的設置應該小於dirty_expire_centisecs，但也不能太小，太小I/O太頻繁，反而
使系統性能下降。具體可能需要在生產環境上測試。據說1:6 (dirty_expire_centisecs : dirty_writeback_centisecs )的比例比較好。

/proc/sys/vm/dirty_expire_centisecs
聲明Linux內核寫緩衝區裡面的數據多“舊”了之後，pdflush進程就開始考慮寫到磁盤中去。單位是1/100秒。缺省是30000，也就是30秒的數據就算舊了，
將會刷新磁盤。對於特別重載的寫操作來說，這個值適當縮小也是好的，但也不能縮小太多，因為縮小太多也會導致IO提高太快。
當然，如果你的系統內存比較大，並且寫入模式是間歇式的，並且每次寫入的數據不大（比如幾十M），那麼這個值還是大些的好。

/proc/sys/vm/vfs_cache_pressure
表示內核回收用於directory和inode cache內存的傾向；缺省值100表示內核將根據pagecache和swapcache，把directory和inode cache保持在一個合理的百分比；
降低該值低於100，將導致內核傾向於保留directory和inode cache；增加該值超過100，將導致內核傾向於回收directory和inode cache

/proc/sys/vm/min_free_kbytes
表示強制Linux VM最低保留多少空閒內存（Kbytes）。
缺省設置：724（512M物理內存）

/proc/sys/vm/nr_pdflush_threads
表示當前正在運行的pdflush進程數量，在I/O負載高的情況下，內核會自動增加更多的pdflush進程。

/proc/sys/vm/overcommit_memory
指定了內核針對內存分配的策略，其值可以是0、1、2。
0，表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。
1，表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。
2，表示內核允許分配超過所有物理內存和交換空間總和的內存（參照overcommit_ratio）。
缺省設置：0

/proc/sys/vm/overcommit_ratio
如果overcommit_memory=2，可以過載內存的百分比，通過以下公式來計算系統整體可用內存。系統可分配內存=交換空間+物理內存*overcommit_ratio/100
缺省設置：50（%）

/proc/sys/vm/page - cluster
表示在寫一次到swap區的時候寫入的頁面數量，0表示1頁，1表示2頁，2表示4頁。
缺省設置：3（2的3次方，8頁）

/proc/sys/vm/swapiness
表示系統進行交換行為的程度，數值（0-100）越高，越可能發生磁盤交換。

想要開機後長置更改：
vi  /etc/sysctl.conf
add "vm.dirty_ratio = 40"