提高活動目錄性能與安全的LSASS進程
對活動目錄來說有著最高級別的重要性但通常很少得到管理員理解的活動目錄相關服務就是本地安全權威子系統（LSASS）。
在所有運行在域控制器（DC）上的活動目錄服務中，我可以打賭，LSASS.exe系統錯誤或失敗是最常見且對該環境有最大影響。因此，活動目錄管理員和支持人員理解LSASS的工作及故障排解的途徑非常重要。
特別推薦：聽專家講述Windows活動目錄
LSASS是什么？
LSASS.exe主要任務是處理認證請求并允許或拒絕對用戶請求的訪問。這些請求來自于域登錄嘗試或是回答用戶請求的其它服務或應用。在所有事件中，如果LSASS不及時處理請求，該請求可能失敗或者長時間推后。
LSASS.exe主要消耗每個域控制器上的內存和CPU資源。對這些資源的消耗如果達到某一程度，域控制器可能會：
無法滿足其它服務的要求，如活動目錄復制。
由于LSASS需要的資源比域控制器可提供的更多，回應認證請求和LDAP搜索的速度變慢。
終止或中斷所有服務。
這不是一個新問題，微軟在KB和TechNet上的文章中都很好地記錄了該問題。說到描述該問題和規定LSASS的功能，KB 308356是其中最好的文章之一，盡管它更多地傾向于Windows 2000。它表明，該方案不是得到更多內存/CPU就是減少域控制器上的負載。
LSASS問題出現的原因
了解什么導致LSASS消耗資源很重要。首先，當域控制器啟動時，NTDS.dit（活動目錄的Jet數據庫）至少部分和LSASS負載到相同的內存空間。當然，這受到了可用物理內存的限制。舉例來說，如果NTDS.dit是2GB，基于LSASS處理的活動，你也許希望LSASS.exe的工作集大小是3-4GB。
這個認證活動包括LDAP查詢，全天都不一樣。我觀察到的是重啟后LSASS.exe內存用量的銳減，最終其變得平緩。和用量需求波動一樣，內存集會達到平衡并通過其它服務和進程返回使用的內存。如果內存使用繼續隨時間波動，可能是因為內存泄漏。
確定性能問題是否與LSASS相關
每個人都會部的問題是“我如何知道LSASS 何時使用了過多的內存或CPU？”答案是，根據情況變化。從KB 308356和其它文章中我們了解，LSASS.exe會運用什么內存和CPU。TechNet上的微軟博客提供了一個好方法來確定多少內存算太多。本質上，文章主旨是你需要建立基準，然后從該基準觀察差異。
運用性能監控器（PerfMon），我一般通過為進程對象和LSASS實例設置一個計數器來完成。我設置工作集和工作集峰值，當然，加入CPU利用率的百分數來測量CPU性能也很重要。我一般建立至少48小時的基準并設置收集至少1000個樣例的間隔。如果你想你還可以做更多。
在缺少基準時，微軟博客建議，將調查的CPU利用率保持或重復在80%或以上。周期性的下降不是問題，這也是預期的。再者，使用PerfMon分析計數器之前計下的數可以確定其中是否有問題。
注意：如果你不是PerfMon專家，考慮使用第三方工具“日志性能分析器”（PAL）。它可免費下載，且使用簡便。只要確定使用的是叫做活動目錄的“臨界值文件”。它會為你做基礎分析，在收集的計數上顯示警告和錯誤的臨界值。
正如之前所說的，除了認證請求，LDAP查詢由LSASS.exe處理，并且能消耗額外的資源。在分析LDAP查詢時，不僅要考慮查詢的次數和頻率，還要考慮它們的來源和效率。我曾經看過文章說高效的LADP查詢應該返回不少于10%的“命中率”。也就是說，如果你發起一次LDAP查詢，它搜索到1000個活動目錄對象，它應該返回100個成功的命中對象。效率低的LDAP查詢可以快速使用大多資源并在DC上創建即時的障礙。
整理LSASS相關問題
大體來講，解析LSASS性能問題的方法包括：
通過收集用戶模式內存抽取來識別LSASS.exe進程使用的來源并分析問題來源來解析它。
識別來源和過度及低效LDAP搜索的起因。
通過為DC添加更多域控制器或遷移到64位大型內存平臺來向活動目錄環境添加更大馬力。
【編輯推薦】
