|
| Sun ONE Directory Server 5.2 安裝和調整指南 |
Directory Server 快取記憶體和磁碟上的目錄資訊，以便能夠更快速地回應用戶端的要求。適當地調整快取，可將處理用戶端要求時，對存取磁碟子系統的需求降到最低。
注意 除非快取經過調整並且運作順暢，否則其他調整對效能的影響很有限。
快取類型
Directory Server 處理三種快取類型，如表 6-1 中所述。
表 6-1 快取
快取類型
描述
資料庫
每個 Directory Server 實例都有一個資料庫快取，其中儲存了使用資料庫格式的索引和項目。
項目
每個尾碼都有一個項目快取，其中儲存了前一作業期間擷取自資料庫的項目，該項目並已格式化，以便能快速傳送至用戶端的應用程式。
匯入
每個 Directory Server 實例都有一個匯入快取，其結構類似於資料庫快取，並且是在大量載入時使用。
當在以下作業系統中以及從磁碟子系統的 I/O 緩衝區處理 Directory Server 時，檔案系統快取亦有助於 Directory Server。
圖 6-1 顯示處理三個尾碼的 Directory Server 實例快取，而每個尾碼都有它自己的項目快取。實體被設定為可在不同的磁碟子系統中處理重要磁碟活動、放置異動記錄檔、資料庫和其他檔案與記錄檔，如第 8 章「調整記錄」中所建議。
圖 6-1 內容中的項目和資料庫快取
資料庫快取
每個 Directory Server 實體都有一個資料庫快取。資料庫快取儲存含有索引和項目之資料庫的頁面。每個頁面並不是一個項目，而是含有部分資料庫的記憶體片段。您可以指定資料庫快取大小 (nsslapd-dbcachesize)。資料庫快取大小的變更會在重新啟動伺服器後生效，並且使用伺服器啟動時所配置的資料庫快取空間。
Directory Server 移動資料庫檔案和資料庫快取之間的頁面，以維持最大的資料庫快取大小。 Directory Server 用於資料庫快取的實際記憶體大小，最多可能會超過您所指定大小的 25%，因為系統需要額外的記憶體來管理本身的資料庫快取。
當使用的資料庫快取非常大時，可透過經驗測試、並利用 Solaris 系統上的 pmap(1) 等工具來監控記憶體使用狀況，以驗證 Directory Server 使用的記憶體大小並未超過可用的實體記憶體。超過可用實體記憶體將會使系統開始重複呼叫，而導致效能嚴重降低。
亦可使用 ps(1) 公用程式 (顯示於 UNIX 平台 Directory Server 支援上) 加上 -p pid 與 -o format 選項，來檢視諸如 Directory Server (ns-slapd) 之類的特定處理序所用之目前記憶體。在 Windows 系統上，[工作管理員處理序] 標籤頁列出基於每個處理序的記憶體使用率 (slapd.exe)。如需詳細資料，請參閱作業系統的說明文件。
使用 32 位元的伺服器時，實際的資料庫快取大小必須限制在 2 GB (含) 以下。
注意 在 Windows 和 AIX 平台上，請勿配置超過 1 GB (1,073,741,824 位元組) 的資料庫快取。
有關 nsslapd-dbcachesize 值有效範圍的詳細資料，請參閱「Sun ONE Directory Server 參考手冊」。
項目快取
項目快取儲存最近存取的項目，這些項目已格式化以傳送給用戶端應用程式。您指定尾碼的項目快取大小 (nsslapd-cachememsize) 和最大項目數 (nsslapd-cachesize)。項目快取依需求配置。
Directory Server 可以非常有效率地自項目快取中傳回項目，因為儲存在此快取中的項目已經格式化。資料庫中的項目是儲存成位元組的原始字串，因此在傳送給用戶端應用程式前必須格式化 (並且儲存在項目快取中)。
指定項目快取大小時，需要知道 nsslapd-cachememsize 表示 Directory Server 從基礎記憶體配置程式庫要求多少記憶體。依據記憶體配置程式庫如何處理這樣的要求，實際使用的記憶體可能遠遠大於最終用於 Directory Server 的項目快取之有效記憶體最大數量。
Directory Server 程序實際使用的記憶體主要依存於使用的記憶體配置程式庫，以及快取的項目。具有很多小屬性值的項目一般比具有較少大屬性值的項目要求更多的額外資源。
使用 32 位元的伺服器時，實際的項目快取大小必須限制在 2 GB (含) 以下。
注意 在 AIX 平台上，Directory Server 是用 maxdata = 0x50000000 所建立，允許您為資料庫快取和項目快取各配置 1 GB。如果您必須變更 maxdata 的值，請聯絡 Sun ONE 支援人員。
有關 nsslapd-cachememsize 和 nsslapd-cachesize 值有效範圍的詳細資料，請參閱「Sun ONE Directory Server 參考手冊」。
匯入快取
匯入快取僅在尾碼初始化期間建立和使用，也稱為大量載入或匯入。如果部署只涉及到 offline 尾碼的初始化，則匯入快取和資料庫快取不會一起使用，所以您不需要在彙總快取大小時同時加入它們，如「總彙總快取大小」中所述。您指定匯入快取大小 (nsslapd-import-cachesize)。匯入快取大小的變更會在下一次尾碼重設和初始化時生效，並使用為初始化所配置的匯入快取，而該快取會在初始化後釋放。
Directory Server 會以處理資料庫快取相同的方式來處理匯入快取。因此請確定有足夠的實體記憶體可供使用以防止交換。
使用 32 位元的伺服器時，實際的匯入快取大小必須限制在 2 GB (含) 以下。有關 nsslapd-import-cachesize 值有效範圍的詳細資料，請參閱「Sun ONE Directory Server 參考手冊」。
檔案系統快取
作業系統將 Directory Server 快取和其他應用程式沒有使用的可用記憶體配置給檔案系統快取。此快取儲存最近讀取自磁碟的資料，並讓後續的要求可以從這裡取得從快取所複製的資料，而不需再從磁碟讀取一次。因記憶體存取比磁碟存取快上許多倍，所以保留一些實體記憶體作為檔案系統快取可增進效能。
如需有關檔案系統快取的詳細資料，請參閱作業系統的說明文件。
總彙總快取大小
同時使用的所有快取總和，必須保持小於可用實體記憶體的總大小，減去檔案系統快取原訂使用的記憶體。使用 32 位元的伺服器時，這表示實際的總彙總快取大小必須限制在 2 GB (含) 以下。使用的總快取大小可能遠大於指定的大小。如需如何檢查快取大小以及 Directory Server 程序大小是否沒有超過可用實際記憶體的提示，請參閱「資料庫快取」。
注意 在 Windows 平台上，應用程式可用的最大位址空間為 2 GB。如果總彙總快取大小超過這個限制，則 Directory Server 便會退出並出現錯誤訊息。
如果尾碼在 Directory Server 處於線上狀態時初始化 (大量載入)，則資料庫、項目和匯入快取大小的總和應該保持小於可用實體記憶體的總大小。
表 6-2 尾碼初始化 (匯入) 作業和快取的使用
快取類型
離線匯入
線上匯入
資料庫
否
是
項目
是
是
匯入
是
是
如果所有尾碼初始化都是在 Directory Server 停止時離線執行的，則此限制範圍左右可能都適用。在這種情況下，匯入快取並不會與資料庫快取共存，因此您可以配置相同的記憶體給匯入快取和資料庫快取，前者是供離線尾碼初始化使用，而後者是在線上使用。但是，如果您選擇執行此特殊的情況，則請確定沒有人在執行的系統上執行線上大量載入。同時使用的快取總和，仍然必須維持小於可用實體記憶體的總大小。
如何搜尋使用快取
圖 6-2 說明 Directory Server 如何同時處理指定 Base DN 的搜尋與使用篩選器的搜尋。個別的線代表存取不同記憶體層級的執行緒，而虛線代表透過有效調整的最小化步驟。
圖 6-2 搜尋和快取
基礎搜尋處理
如圖所示，基礎搜尋 (指定 Base DN 的搜尋) 是 Directory Server 所處理最簡單的搜尋類型。若要處理這類搜尋，Directory Server：
- 嘗試從項目快取中擷取擁有指定 Base DN 的項目。
如果在其中找到項目，Directory Server 會檢查該候選項目是否符合搜尋所提供的篩選器。
如果該項目符合，Directory Server 便會快速地將已格式化的快取項目傳回給用戶端應用程式。
- 嘗試從資料庫快取擷取項目。
如果在其中找到項目，Directory Server 會將項目複製到尾碼的項目快取中，然後以在項目快取中找到該項目的方式來進行處理。
- 嘗試從資料庫本身擷取項目。
如果在其中找到項目，Directory Server 會將項目複製到資料庫快取中，然後以在資料庫快取中找到該項目的方式來進行處理。
樹狀子目錄和單層搜尋處理
亦如圖 6-2 中所示，在樹狀子目錄或樹狀目錄的層級中搜尋時，涉及額外的處理，以處理數組的項目。若要處理這類搜尋，Directory Server：
- 嘗試從資料庫快取的索引中，建立一組符合篩選器的候選項目。
如果沒有顯示適當的索引，則必須從資料庫本身的相關項目中產生一組候選項目。
- 處理各候選項目經由：
- 執行基礎搜尋以擷取項目。
- 檢查項目是否符合搜尋所提供的篩選器。
- 如果項目符合篩選器，則將項目傳回給用戶端應用程式。
這樣，Directory Server 便可避免在記憶體中建構組合。
理想情況下，在調整 Directory Server 之前您知道要執行何種搜尋。而在實際執行時，請透過經驗測試來驗證您的假設。
更新如何使用快取
圖 6-3 說明 Directory Server 如何處理更新。個別的線代表存取不同記憶體層級的執行緒，而虛線代表透過有效調整的最小化步驟。
圖 6-3 更新和快取
更新涉及到的處理比搜尋要多。若要處理更新，Directory Server：
- 執行 Base DN 搜尋擷取項目以進行更新，或是在新增尚不存在的作業時進行驗證。
- 變更資料庫快取時會更新索引，特別是受更新影響的任何索引。
如果受更新影響的資料尚未載入資料庫快取，則此步驟在相關資料載入快取時會導致產生磁碟活動。
- 將與變更有關的資訊寫入異動紀錄檔，等待資訊排清到磁碟中。
如需詳細資訊，請參閱「交易記錄」。
- 將更新項目格式化，並將它複製到尾碼的項目快取中。
- 將成功更新的認可傳回給用戶端應用程式。
尾碼初始化如何使用快取
圖 6-4 說明 Directory Server 如何處理尾碼初始化，也稱為大量載入匯入。個別的線代表存取不同記憶體層級的執行緒，而虛線代表透過有效調整的最小化步驟。
圖 6-4 尾碼初始化 (大量載入) 和快取
若要初始化尾碼，Directory Server：
- 從 LDIF 啟動執行緒以餵送項目快取，此項目快取是作為緩衝區。
- 啟動每個受影響索引的執行緒，並啟動執行緒以在匯入快取中建立項目。這些執行緒會消耗餵送到項目快取中的項目。
- 當匯入快取用盡時，將從資料庫檔案進行讀寫。
Directory Server 在尾碼初始化期間可能也會寫入記錄訊息，但並不會寫入異動記錄檔。
Directory Server 所提供的尾碼初始化工具，如 ldif2db (/usr/sbin/directoryserver ldif2db)，提供與快取點擊率和匯入流量相關的回饋。若快取點擊率和匯入流量同時降低，即表示匯入快取可能太小。請考慮增加匯入快取大小。
搜尋最佳化
為達到最佳效能，請盡量快取記憶體中的目錄資料。為防止目錄從磁碟讀取資訊，您必須限制磁碟 I/O 瓶頸。有幾種不同的方式可達成此目的，而採取的方式則視您樹狀目錄、可用的記憶體數量與所使用的硬體而定。根據您的部署，您可以選擇配置較多或較少的記憶體給項目和資料庫快取，以最佳化搜尋效能。此外，您可以選擇跨越不同伺服器上的 Directory Server 使用者分散搜尋。
記憶體中的所有項目和索引
想像最佳的情況。資料庫和項目快取適合可用的實體記憶體。項目快取大到足以儲存目錄中的所有項目。資料庫快取大到最少足以儲存所有索引。在這種情況下，搜尋會找到快取中的所有項目。Directory Server 永遠不需到檔案系統快取或磁碟中來擷取項目。
在這種情況下，請確定資料庫快取即使在更新後也能包含所有資料庫索引。當空間被資料庫快取中的索引用盡時，對於每次提出的搜尋要求，Directory Server 都必須從磁碟讀取索引，從而嚴重影響到流量。Directory Server Console 會在 [狀態] 標籤下顯示點擊率和其他有用的資訊，如圖 6-5 中所示。
圖 6-5 使用 Directory Server Console 監控快取點擊率
此外，透過搜尋也可以監控呼叫和快取活動，其方法是從指令行輸入：
$ ldapsearch -D admin -w password \
-b cn=monitor,cn=database_name,cn=ldbm database,cn=plugins,cn=config若要約略估計符合資料庫快取之.db3 檔案中使用的所有資料庫索引所需的記憶體數量，請使用下列公式。當對典型項目使用預設索引組態時，此公式幾乎非常準確，但該項目必須沒有類似相片的大型二進位屬性。
nsslapd-dbcachesize = 1.2 x SUM所有 .db3 檔案(檔案大小)
若要約略估計符合項目快取之項目快取插槽的數目，以及所有項目所需的記憶體數量，請使用下列公式。同樣地，當對典型項目使用預設索引組態時，此公式幾乎非常準確，但該項目必須沒有類似相片的大型二進位屬性。
nsslapd-cachesize = 4.5 x (LDIF 中的項目數目)
nsslapd-cachememsize = 3.8 x (id2entry.db3 檔案大小)
透過經驗測試進行驗證和修正估計。特別是項目快取所用的記憶體大小可能比您為它們配置的大很多。
大量記憶體，32 位元 Directory Server
想像一下：系統擁有足夠的記憶體，它可以將所有資料儲存到項目和資料庫快取中，但不支援 64 位元 Directory Server 處理序。例如，如果硬體約束防止您在 Solaris 系統上執行部署，則關鍵是依 32 位元處理序的記憶體限制適當調整快取的大小，然後將可用記憶體留給檔案系統快取。
注意 可與系統上的其他處理序 (特別是基於檔案的作業) 共用檔案系統快取。因而較之其他快取，它會非常難以控制，特別是在專供 Directory Server 使用的系統上。
系統可能會將檔案系統快取重新配置給其他處理序。
較少記憶體，部分檔案系統快取
想像系統沒有足夠的可用記憶體，它無法將所有資料儲存到項目和資料庫快取中，但它仍然擁有重要的可用記憶體。這個案例的關鍵是避免合併的項目和資料庫快取大小，超過可用的實體記憶體，這會導致繁重的虛擬記憶體呼叫，並使系統進入虛擬的終止狀態。
請考慮將可用記憶體保留給檔案系統快取，並將項目快取和資料庫快取大小設定成較小的值，如 500 KB。這樣做的話，能允許系統在檔案系統快取中保留足夠的資料，並在 Directory Server 必須重複地從磁碟讀取項目和索引之前，在快取中結束搜尋。
或者，如果搜尋樣式較不隨機的話，您可以選擇設定較高的項目和資料庫快取，但前提是假設特定部署中的大部分搜尋，皆存取目錄中所有項目的相同小子集，而進行這類搜尋時快取項目和索引的好處，與處理偶發異常搜尋要求的成本相抵銷。透過經驗測試進行驗證和修正假設。
較少記憶體，較少檔案系統快取
想像系統沒有足夠的可用記憶體，它無法將資料儲存到項目和資料庫快取中，也無法讓系統快取資料到檔案系統快取中。這個案例的關鍵是充分利用您所擁有的可用記憶體。
請考慮儘量降低項目和資料庫快取的大小，並儘可能地將記憶體都保留給檔案系統快取。將記憶體保留給檔案系統快取，至少能避免 3 到 4.5 倍的項目擴充到資料庫或項目中，理論上可限制磁碟 I/O 活動。透過特定部署的經驗測試來驗證這個假設。
更新最佳化
為達到最佳的更新效能，請先移除所觀察到的任何異動記錄檔瓶頸。如需詳細資訊，請參閱「交易記錄」。
接著，請嘗試提供足夠的記憶體給資料庫快取，以處理記憶體中的更新資料並將磁碟活動降至最低。您可以藉由讀取 Directory Server Console 中的點擊率以監控資料庫快取的功效。Directory Server Console 會在 [狀態] 標籤下顯示尾碼的點擊率，如圖 6-5 中所示。
同時嘗試保留重要的記憶體供檔案系統快取使用。當 Directory Server 執行一段時間後，檔案系統快取應該包含足夠的項目和索引，而使系統不再需要讀取磁碟。更新應該會影響記憶體中的資料庫快取，只有少數情況下會排清記憶體內大型資料庫快取中的資料。
將資料排清到磁碟本身也是一個瓶頸，因此將資料庫儲存到不同的 RAID 系統 (如 Sun StorEdge� 磁碟陣列) 可以幫助改善更新效能。您可以使用 Solaris 系統上的公用程式來脫離潛在的 I/O 瓶頸，如 iostat(1M)。有關在 Windows 系統上處理 I/O 瓶頸的詳細資料，請參照 Windows 說明。
快取填充和監控
填充快取是表示將資料填入其中，這樣後續的 Directory Server 行為才會反映出正常的操作效能，而不會出現揚升的情況。在測量和分析潛在的最佳化之前填充快取。
使用 ldapsearch 公用程式填充尾碼的項目快取。例如：
$ ldapsearch -D directoryManager -w password -b suffix objectclass=\* > /dev/null
執行搜尋以填充資料庫快取，特別是將索引載入快取中。您可以利用 (mail=*) 等篩選器來執行搜尋，以填充存在的索引。對於其他索引，請考慮使用套用篩選器格式的 Sun ONE Directory Server Resource Kit searchrate 公用程式，搜尋各屬性所有可能的值以進行索引。換句話說，例如要根據 mail 屬性來檢查相等搜尋的效能，請先產生一個檔案，該檔案的每一行都針對各個郵件位址顯示一個電子郵件位址，然後使用 searchrate 公用程式來執行使用檔案的搜尋。例如：
$ searchrate -b suffix -f "(mail=%s)" -i mail.file -K -t 10
請考慮使用 -K 和 -t 以節省時間。當與 -K 選項一起使用時，searchrate 會保持連線狀態，您只需繫結一次，不需每次搜尋時都繫結。您可用 -t 選項指定要使用多少執行緒。如需有關 searchrate 公用程式的詳細資料，請參閱「Sun ONE Directory Server Resource Kit 說明文件」。您可以依照「下載目錄伺服器工具」中的說明，取得 Sun ONE Directory Server Resource Kit。
填充其他快取後，便可以填充可用的檔案系統快取。雖然您無法保證檔案系統快取中的資訊未被排清，但填充檔案系統快取仍可改善揚升時間。若要在 UNIX 系統上填充檔案系統快取，請以超級使用者身份使用 dd(1M) 命令。例如在預設位置具有資料庫檔案的 Solaris 系統上：
# for db in ServerRoot/slapd-serverID/db/*/*.db3
> do
> dd if=厜wd?$db of=/dev/null bs=512k
> done
0+1 records in
0+1 records out
...當快取填充完後，您可以執行測試，並監控快取調整是否有產生所需的結果。當您選擇 [狀態] 標籤底下的 [尾碼] 節點時，Directory Server Console 會顯示快取的監控資訊，如圖 6-5 中所示。此外，透過搜尋也可以監控呼叫和快取活動，其方法是從指令行輸入：
$ ldapsearch -D admin -w password \
-b cn=monitor,cn=database_name,cn=ldbm\ database,cn=plugins,cn=config如果資料庫快取大小夠大，並且快取已經填充，那麼點擊率 (dbcachehitratio) 應該很高，而讀取的頁數 (dbcachepagein)，以及寫出的清除頁數 (dbcacheroevict) 則應該很低。在此處，「高」和「低」是相對於部署限制的。
如果尾碼的項目快取大小夠大，並且快取已經填充，那麼點擊率 (entrycachehitratio) 應該很高。項目快取大小 (currententrycachesize) 不應超過大小最大值 (maxentrycachesize) 的 80%。最後，項目 (currententrycachecount) 中的大小應該等於或非常接近尾碼中項目的總數。
其他最佳化
調整快取大小僅代表一種改善搜尋、更新或大量載入速率的方法。當您調整快取時，快取的效能瓶頸便會移到系統的其他部分。如需詳細資訊，請參閱本指南的其他章節。