7．磁盤緩存基礎
7.1 cache_dir指令
cache_dir指令是squid.conf配置文件裏最重要的指令之一。它告訴squid以何種方式存儲cache文件到磁盤的什麼位置。cache_dir指令取如下參數：
cache_dir scheme directory size L1 L2 [options]
7.1.1 參數：Scheme
Squid支持許多不同的存儲機制。默認的（原始的）是ufs。依賴於操作系統的不同，你可以選擇不同的存儲機制。在./configure時，你必須使用--enable-storeio=LIST選項來編譯其他存儲機制的附加代碼。我將在8.7章討論aufs,diskd,coss和null。現在，我僅僅討論ufs機制，它與aufs和diskd一致。
7.1.2 參數：Directory
該參數是文件系統目錄，squid將cache對象文件存放在這個目錄下。正常的，cache_dir使用整個文件系統或磁盤分區。它通常不介意是否在單個文件系統分區裏放置了多個cache目錄。然而，我推薦在每個物理磁盤中，僅僅設置一個cache目錄。例如，假如你有2個無用磁盤，你可以這樣做：
# newfs /dev/da1d # newfs /dev/da2d # mount /dev/da1d /cache0 # mount /dev/da2d /cache1
然後在squid.conf裏增加如下行：
cache_dir ufs /cache0 7000 16 256
cache_dir ufs /cache1 7000 16 256
假如你沒有空閒硬盤，當然你也能使用已經存在的文件系統分區。選擇有大量空閒空間的分區，例如/usr或/var，然後在下面創建一個新目錄。例如：
# mkdir /var/squidcache
然後在squid.conf裏增加如下一行：
cache_dir ufs /var/squidcache 7000 16 256
7.1.3 參數：Size
該參數指定了cache目錄的大小。這是squid能使用的cache_dir目錄的空間上限。計算出合理的值也許有點難。你必須給臨時文件和swap.state日誌，留出足夠的自由空間（見13.6章）。我推薦掛載空文件系統，可以運行df：
% df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da1d 3037766 8 2794737 0% /cache0 /dev/da2d 3037766 8 2794737 0% /cache1
這裏你可以看到文件系統有大約2790M的可用空間。記住，UFS保留了部分最小自由空間，這裏約是8%，這就是squid爲什麼不能使用全部3040M空間的原因。
你也許試圖分配2790M給cache_dir。如果cache不很繁忙，並且你經常輪轉日誌，那麼這樣做也許可行。然而，爲安全起見，我推薦保留10%的空間。這些額外的空間用於存放squid的swap.state文件和臨時文件。
注意cache_swap_low指令也影響了squid使用多少空間。我將在7.2章裏討論它的上限和下限。
底線是，你在初始時應保守的估計cache_dir的大小。將cache_dir設爲較小的值，並允許寫滿cache。在squid運行一段時間後，cache目錄會填滿，這樣你可以重新評估cache_dir的大小設置。假如你有大量的自由空間，就可以輕鬆的增加cache目錄的大小了。
7.1.3.1 Inodes
Inodes（i節點）是unix文件系統的基本結構。它們包含磁盤文件的信息，例如許可，屬主，大小，和時間戳。假如你的文件系統運行超出了i節點限制，就不能創造新文件，即使還有空間可用。超出i節點的系統運行非常糟糕，所以在運行squid之前，你應該確認有足夠的i節點。
創建新文件系統的程序（例如,newfs或mkfs）基於總空間的大小，保留了一定數量的i節點。這些程序通常允許你設置磁盤空間的i節點比率。例如，請閱讀newfs和mkfs手冊的-i選項。磁盤空間對i節點的比率，決定了文件系統能實際支持的文件大小。大部分unix系統每4KB創建一個i節點，這對squid通常是足夠的。研究顯示，對大部分cache代理，實際文件大小大約是10KB。你也許能以每i節點8KB開始，但這有風險。
你能使用df -i命令來監視系統的i節點，例如：
% df -ik Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a 197951 57114 125001 31% 1413 52345 3% / /dev/ad0s1f 5004533 2352120 2252051 51% 129175 1084263 11% /usr /dev/ad0s1e 396895 6786 358358 2% 205 99633 0% /var /dev/da0d 8533292 7222148 628481 92% 430894 539184 44% /cache1 /dev/da1d 8533292 7181645 668984 91% 430272 539806 44% /cache2 /dev/da2d 8533292 7198600 652029 92% 434726 535352 45% /cache3 /dev/da3d 8533292 7208948 641681 92% 427866 542212 44% /cache4
如果i節點的使用（%iused）少於空間使用（Capacity），那就很好。不幸的是，你不能對已經存在的文件系統增加更多i節點。假如你發現運行超出了i節點，那就必須停止squid，並且重新創建文件系統。假如你不願意這樣做，那麼請削減cache_dir的大小。
7.1.3.2 在磁盤空間和進程大小之間的聯繫
Squid的磁盤空間使用也直接影響了它的內存使用。每個在磁盤中存在的對象，要求少量的內存。squid使用內存來索引磁盤數據。假如你增加了新的cache目錄，或者增加了磁盤cache大小，請確認你已有足夠的自由內存。假如squid的進程大小達到或超過了系統的物理內存容量，squid的性能下降得非常塊。
Squid的cache目錄裏的每個對象消耗76或112字節的內存，這依賴於你的系統。內存以StoreEntry, MD5 Digest, 和LRU policy node結構來分配。小指令（例如，32位）系統，象那些基於Intel Pentium的，取76字節。使用64位指令CPU的系統，每個目標取112字節。通過閱讀cache管理的內存管理文檔，你能發現這些結構在你的系統中耗費多少內存（請見14.2.1.2章）。
不幸的是，難以精確預測對於給定數量的磁盤空間，需要使用多少附加內存。它依賴於實際響應大小，而這個大小基於時間波動。另外，Squid還爲其他數據結構和目的分配內存。不要假設你的估計正確。你該經常監視squid的進程大小，假如必要，考慮削減cache大小。
7.1.4 參數：L1和L2
對ufs,aufs,和diskd機制，squid在cache目錄下創建二級目錄樹。L1和L2參數指定了第一級和第二級目錄的數量。默認的是16和256。圖7-1顯示文件系統結構。
Figure 7-1. 基於ufs存儲機制的cache目錄結構
某些人認爲squid依賴於L1和L2的特殊值，會執行得更好或更差。這點聽起來有關係，即小目錄比大目錄被檢索得更快。這樣，L1和L2也許該足夠大，以便L2目錄的文件更少。例如，假設你的cache目錄存儲了7000M，假設實際文件大小是10KB，你能在這個cache_dir裏存儲700,000個文件。使用16個L1和256個L2目錄，總共有4096個二級目錄。700,000/4096的結果是，每個二級目錄大約有170個文件。
如果L1和L2的值比較小，那麼使用squid -z創建交換目錄的過程，會執行更快。這樣，假如你的cache文件確實小，你也許該減少L1和L2目錄的數量。
Squid給每個cache目標分配一個唯一的文件號。這是個32位的整數，它唯一標明磁盤中的文件。squid使用相對簡單的算法，將文件號轉換位路徑名。該算法使用L1和L2作爲參數。這樣，假如你改變了L1和L2，你改變了從文件號到路徑名的映射關係。對非空的cache_dir改變這些參數，導致存在的文件不可訪問。在cache目錄激活後，你永不要改變L1和L2值。
Squid在cache目錄順序中分配文件號。文件號到路徑名的算法（例如，storeUfsDirFullPath( )），用以將每組L2文件映射到同樣的二級目錄。Squid使用了參考位置來做到這點。該算法讓HTML文件和它內嵌的圖片更可能的保存在同一個二級目錄中。某些人希望squid均勻的將cache文件放在每個二級目錄中。然而，當cache初始寫入時，你可以發現僅僅開頭的少數目錄包含了一些文件，例如：
% cd /cache0; du -k 2164 ./00/00 2146 ./00/01 2689 ./00/02 1974 ./00/03 2201 ./00/04 2463 ./00/05 2724 ./00/06 3174 ./00/07 1144 ./00/08 1 ./00/09 1 ./00/0A 1 ./00/0B
這是完全正常的，不必擔心。
7.1.5 參數：Options
Squid有2個依賴於不同存儲機制的cache_dir選項：read-only標籤和max-size值。
7.1.5.1 read-only
read-only選項指示Squid繼續從cache_dir讀取文件，但不往裏面寫新目標。它在squid.conf文件裏看起來如下：
cache_dir ufs /cache0 7000 16 256 read-only
假如你想把cache文件從一個磁盤遷移到另一個磁盤，那麼可使用該選項。如果你簡單的增加一個cache_dir，並且刪除另一個，squid的命中率會顯著下降。在舊目錄是read-only時，你仍能從那裏獲取cache命中。在一段時間後，就可以從配置文件裏刪除read-only緩存目錄。
7.1.5.2 max-size
使用該選項，你可以指定存儲在cache目錄裏的最大目標大小。例如：
cache_dir ufs /cache0 7000 16 256 max-size=1048576
注意值是以字節爲單位的。在大多數情況下，你不必增加該選項。假如你做了，請盡力將所有cache_dir行以max-size大小順序來存放（從小到大）。
7.2 磁盤空間基準
cache_swap_low和cache_swap_high指令控制了存儲在磁盤上的對象的置換。它們的值是最大cache體積的百分比，這個最大cache體積來自於所有cache_dir大小的總和。例如：
cache_swap_low 90 cache_swap_high 95
如果總共磁盤使用低於cache_swap_low，squid不會刪除cache目標。如果cache體積增加，squid會逐漸刪除目標。在穩定狀態下，你發現磁盤使用總是相對接近cache_swap_low值。你可以通過請求cache管理器的storedir頁面來查看當前磁盤使用狀況（見14.2.1.39章）。
請注意，改變cache_swap_high也許不會對squid的磁盤使用有太大效果。在squid的早期版本里，該參數有重要作用；然而現在，它不是這樣了。
7.3 對象大小限制
你可以控制緩存對象的最大和最小體積。比maximum_object_size更大的響應不會被緩存在磁盤。然而，它們仍然是代理方式的。在該指令後的邏輯是，你不想某個非常大的響應來浪費空間，這些空間能被許多小響應更好的利用。該語法如下：
maximum_object_size size-specification
如下是一些示例：
maximum_object_size 100 KB maximum_object_size 1 MB maximum_object_size 12382 bytes maximum_object_size 2 GB
Squid以兩個不同的方法來檢查響應大小。假如響應包含了Content-Length頭部，squid將這個值與maximum_object_size值進行比較。假如前者大於後者，該對象立刻不可緩存，並且不會消耗任何磁盤空間。
不幸的是，並非每個響應都有Content-Length頭部。在這樣的情形下，squid將響應寫往磁盤，把它當作來自原始服務器的數據。在響應完成後，squid再檢查對象大小。這樣，假如對象的大小達到 maximum_object_size限制，它繼續消耗磁盤空間。僅僅當squid在做讀取響應的動作時，總共cache大小纔會增大。
換句話說，活動的，或者傳輸中的目標，不會對squid內在的cache大小值有影響。這點有好處，因爲它意味着squid不會刪除cache裏的其他目標，除非目標不可緩存，並對總共cache大小有影響。然而，這點也有壞處，假如響應非常大，squid可能運行超出了磁盤自由空間。爲了減少發生這種情況的機會，你應該使用reply_body_max_size指令。某個達到reply_body_max_size限制的響應立即被刪除。
Squid也有一個minimum_object_size指令。它允許你對緩存對象的大小設置最低限制。比這個值更小的響應不會被緩存在磁盤或內存裏。注意這個大小是與響應的內容長度（例如，響應body大小）進行比較，後者包含在HTTP頭部裏。
7.4 分配對象到緩存目錄
當squid想將某個可緩存的響應存儲到磁盤時，它調用一個函數，用以選擇cache目錄。然後它在選擇的目錄裏打開一個磁盤文件用於寫。假如因爲某些理由，open()調用失敗，響應不會被存儲。在這樣的情況下，squid不會試圖在其他cache目錄裏打開另一個磁盤文件。
Squid有2個cache_dir選擇算法。默認的算法叫做lease-load；替代的算法是round-robin。
least-load算法，就如其名字的意義一樣，它選擇當前工作負載最小的cache目錄。負載概念依賴於存儲機制。對aufs,coss和diskd機制來說，負載與掛起操作的數量有關。對ufs來說，負載是不變的。在cache_dir負載相等的情況下，該算法使用自由空間和最大目標大小作爲附加選擇條件。
該選擇算法也取決於max-size和read-only選項。假如squid知道目標大小超出了限制，它會跳過這個cache目錄。它也會跳過任何只讀目錄。
round-robin算法也使用負載作爲衡量標準。它選擇某個負載小於100%的cache目錄，當然，該目錄裏的存儲目標沒有超出大小限制，並且不是隻讀的。
在某些情況下，squid可能選擇cache目錄失敗。假如所有的cache_dir是滿負載，或者所有目錄的實際目標大小超出了max-size限制，那麼這種情況可能發生。這時，squid不會將目標寫往磁盤。你可以使用cache管理器來跟蹤squid選擇cache目錄失敗的次數。請見store_io頁（14.2.1.41章），找到create.select_fail行。
7.5 置換策略
cache_replacement_policy指令控制了squid的磁盤cache的置換策略。Squid2.5版本提供了三種不同的置換策略：最少近來使用（LRU），貪婪對偶大小次數（GDSF），和動態衰老最少經常使用（LFUDA)。
LRU是默認的策略，並非對squid，對其他大部分cache產品都是這樣。LRU是流行的選擇，因爲它容易執行，並提供了非常好的性能。在32位系統上，LRU相對於其他使用更少的內存（每目標12對16字節）。在64位系統上，所有的策略每目標使用24字節。
在過去，許多研究者已經提議選擇LRU。其他策略典型的被設計來改善cache的其他特性，例如響應時間，命中率，或字節命中率。然而研究者的改進結果也可能在誤導人。某些研究使用並不現實的小cache目標；其他研究顯示當cache大小增加時，置換策略的選擇變得不那麼重要。
假如你想使用GDSF或LFUDA策略，你必須在./configure時使用--enable-removal-policies選項（見3.4.1章）。Martin Arlitt 和HP實驗室的John Dilley爲squid寫了GDSF和LFUDA算法。你可以在線閱讀他們的文檔：
http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html我在O'Reilly出版的書"Web Caching"，也討論了這些算法。
cache_replacement_policy指令的值是唯一的，這點很重要。不象squid.conf裏的大部分其他指令，這個指令的位置很重要。cache_replacement_policy指令的值在squid解析cache_dir指令時，被實際用到。通過預先設置替換策略，你可以改變cache_dir的替換策略。例如：
cache_replacement_policy lru cache_dir ufs /cache0 2000 16 32 cache_dir ufs /cache1 2000 16 32 cache_replacement_policy heap GDSF cache_dir ufs /cache2 2000 16 32 cache_dir ufs /cache3 2000 16 32
在該情形中，頭2個cache目錄使用LRU置換策略，接下來2個cache目錄使用GDSF。請記住，假如你已決定使用cache管理器的config選項（見14.2.1.7章），這個置換策略指令的特性就非常重要。cache管理器僅僅輸出最後一個置換策略的值，將它置於所有的cache目錄之前。例如，你可能在squid.conf裏有如下行：
cache_replacement_policy heap GDSF cache_dir ufs /tmp/cache1 10 4 4 cache_replacement_policy lru cache_dir ufs /tmp/cache2 10 4 4
但當你從cache管理器選擇config時，你得到：
cache_replacement_policy lru
cache_dir ufs /tmp/cache1 10 4 4
cache_dir ufs /tmp/cache2 10 4 4
就象你看到的一樣，對頭2個cache目錄的heap GDSF設置被丟失了。
7.6 刪除緩存對象
在某些情況下，你必須從squid的cache裏手工刪除一個或多個對象。這些情況可能包括：
- 你的用戶抱怨總接收到過時的數據；
- 你的cache因爲某個響應而“中毒”；
- Squid的cache索引在經歷磁盤I/O錯誤或頻繁的crash和重啓後，變得有問題；
- 你想刪除一些大目標來釋放空間給新的數據；
- Squid總從本地服務器中cache響應，現在你不想它這樣做。
上述問題中的一些可以通過強迫web瀏覽器reload來解決。然而，這並非總是可靠。例如，一些瀏覽器通過載入另外的程序，從而顯示某些類容類型；那個程序可能沒有reload按鈕，或甚至它瞭解cache的情況。
假如必要，你總可以使用squidclient程序來reload緩存目標。簡單的在uri前面使用-r選項：
% squidclient -r http://www.lrrr.org/junk >/tmp/foo
假如你碰巧在refresh_pattern指令裏設置了ignore-reload選項，你和你的用戶將不能強迫緩存響應更新。在這樣的情形下，你最好清除這些有錯誤的緩存對象。
7.6.1 刪除個別對象
Squid接受一種客戶請求方式，用於刪除cache對象。PURGE方式並非官方HTTP請求方式之一。它與DELETE不同，對後者，squid將其轉發到原始服務器。PURGE請求要求squid刪除在uri裏提交的目標。squid返回200（OK）或404（Not Found）。
PURGE方式某種程度上有點危險，因爲它刪除了cache目標。除非你定義了相應的ACL，否則squid禁止PURGE方式。正常的，你僅僅允許來自本機和少數可信任主機的PURGE請求。配置看起來如下：
acl AdminBoxes src 127.0.0.1 172.16.0.1 192.168.0.1 acl Purge method PURGE http_access allow AdminBoxes Purge http_access deny Purge squidclient程序提供了產生PURGE請求的容易方法，如下： % squidclient -m PURGE http://www.lrrr.org/junk
代替的，你可以使用其他工具（例如perl腳本）來產生你自己的HTTP請求。它非常簡單：
PURGE http://www.lrrr.org/junk HTTP/1.0
Accept: */*
注意某個單獨的URI不唯一標明一個緩存響應。Squid也在cache關鍵字裏使用原始請求方式。假如響應包含了不同的頭部，它也可以使用其他請求頭。當你發佈PURGE請求時，Squid使用GET和HEAD的原始請求方式來查找緩存目標。而且，Squid會刪除響應裏的所有variants，除非你在PURGE請求的相應頭部裏指定了要刪除的variants。Squid僅僅刪除GET和HEAD請求的variants。
7.6.2 刪除一組對象
不幸的是，Squid沒有提供一個好的機制，用以立刻刪除一組對象。這種要求通常出現在某人想刪除所有屬於同一臺原始服務器的對象時。
因爲很多理由，squid不提供這種功能。首先，squid必須遍歷所有緩存對象，執行線性搜索，這很耗費CPU，並且耗時較長。當squid在搜索時，用戶會面臨性能下降問題。第二，squid在內存裏對URI保持MD5算法，MD5是單向哈希，這意味着，例如，你不能確認是否某個給定的MD5哈希是由包含"www.example.com"字符串的URI產生而來。唯一的方法是從原始URI重新計算MD5值，並且看它們是否匹配。因爲squid沒有保持原始的URI，它不能執行這個重計算。
那麼該怎麼辦呢？
你可以使用access.log裏的數據來獲取URI列表，它們可能位於cache裏。然後，將它們用於squidclient或其他工具來產生PURGE請求，例如：
% awk '{print $7}' /usr/local/squid/var/logs/access.log /
| grep www.example.com /
| xargs -n 1 squidclient -m PURGE
7.6.3 刪除所有對象
在極度情形下，你可能需要刪除整個cache，或至少某個cache目錄。首先，你必須確認squid沒有在運行。
讓squid忘記所有緩存對象的最容易的方法之一，是覆蓋swap.state文件。注意你不能簡單的刪除swap.state文件，因爲squid接着要掃描cache目錄和打開所有的目標文件。你也不能簡單的截斷swap.state爲0大小。代替的，你該放置一個單字節在裏面，例如：
# echo '' > /usr/local/squid/var/cache/swap.state
當squid讀取swap.state文件時，它獲取到了錯誤，因爲在這裏的記錄太短了。下一行讀取就到了文件結尾，squid完成重建過程，沒有裝載任何目標元數據。
注意該技術不會從磁盤裏刪除cache文件。你僅僅使squid認爲它的cache是空的。當squid運行時，它增加新文件到cache裏，並且可能覆蓋舊文件。在某些情形下，這可能導致你的磁盤使用超出了自由空間。假如這樣的事發生，你必須在再次重啓squid前刪除舊文件。
刪除cache文件的方法之一是使用rm。然而，它通常花費很長的時間來刪除所有被squid創建的文件。爲了讓squid快速啓動，你可以重命名舊cache目錄，創建一個新目錄，啓動squid，然後同時刪除舊目錄。例如：
# squid -k shutdown # cd /usr/local/squid/var # mv cache oldcache # mkdir cache # chown nobody:nobody cache # squid -z # squid -s # rm -rf oldcache &
另一種技術是簡單的在cache文件系統上運行newfs（或mkfs）。這點僅在你的cache_dir使用整個磁盤分區時纔可以運行。
7.7 refresh_pattern
refresh_pattern指令間接的控制磁盤緩存。它幫助squid決定，是否某個給定請求是cache命中，或作爲cache丟失對待。寬鬆的設置增加了你的cache命中率，但也增加了用戶接收過時響應的機會。另一方面，保守的設置，降低了cache命中率和過時響應。
refresh_pattern規則僅僅應用到沒有明確過時期限的響應。原始服務器能使用Expires頭部，或者Cache-Control:max-age指令來指定過時期限。
你可以在配置文件裏放置任意數量的refresh_pattern行。squid按順序查找它們以匹配正則表達式。當squid找到一個匹配時，它使用相應的值來決定，某個緩存響應是存活還是過期。refresh_pattern語法如下：
refresh_pattern [-i] regexp min percent max [options]
例如：
refresh_pattern -i /.jpg$ 30 50% 4320 reload-into-ims refresh_pattern -i /.png$ 30 50% 4320 reload-into-ims refresh_pattern -i /.htm$ 0 20% 1440 refresh_pattern -i /.html$ 0 20% 1440 refresh_pattern -i . 5 25% 2880
regexp參數是大小寫敏感的正則表達式。你可以使用-i選項來使它們大小寫不敏感。squid按順序來檢查refresh_pattern行；當正則表達式之一匹配URI時，它停止搜索。
min參數是分鐘數量。它是過時響應的最低時間限制。如果某個響應駐留在cache裏的時間沒有超過這個最低限制，那麼它不會過期。類似的，max參數是存活響應的最高時間限制。如果某個響應駐留在cache裏的時間高於這個最高限制，那麼它必須被刷新。
在最低和最高時間限制之間的響應，會面對squid的最後修改係數 (LM-factor)算法。對這樣的響應，squid計算響應的年齡和最後修改係數，然後將它作爲百分比值進行比較。響應年齡簡單的就是從原始服務器產生，或最後一次驗證響應後，經歷的時間數量。源年齡在Last-Modified和Date頭部之間是不同的。LM-factor是響應年齡與源年齡的比率。
圖7-2論證了LM-factor算法。squid緩存了某個目標3個小時（基於Date和Last-Modified頭部）。LM-factor的值是50%，響應在接下來的1.5個小時裏是存活的，在這之後，目標會過期並被當作過時處理。假如用戶在存活期間請求cache目標，squid返回沒有確認的cache命中。若在過時期間發生請求，squid轉發確認請求到原始服務器。
圖7-2 基於LM-factor計算過期時間
理解squid檢查不同值的順序非常重要。如下是squid的refresh_pattern算法的簡單描述：
- 假如響應年齡超過refresh_pattern的max值，該響應過期；
- 假如LM-factor少於refresh_pattern百分比值，該響應存活；
- 假如響應年齡少於refresh_pattern的min值，該響應存活；
- 其他情況下，響應過期。
refresh_pattern指令也有少數選項導致squid違背HTTP協議規範。它們如下：
override-expire
該選項導致squid在檢查Expires頭部之前，先檢查min值。這樣，一個非零的min時間讓squid返回一個未確認的cache命中，即使該響應準備過期。
override-lastmod
改選項導致squid在檢查LM-factor百分比之前先檢查min值。
reload-into-ims
該選項讓squid在確認請求裏，以no-cache指令傳送一個請求。換句話說，squid在轉發請求之前，對該請求增加一個If-Modified-Since頭部。注意這點僅僅在目標有Last-Modified時間戳時才能工作。外面進來的請求保留no-cache指令，以便它到達原始服務器。
ignore-reload
該選項導致squid忽略請求裏的任何no-cache指令。
