对活动目录来说有着最高级别的重要性但通常很少得到管理员理解的活动目录相关服务就是本地安全权威子系统（LSASS）。

　　在所有运行在域控制器（DC）上的活动目录服务中，我可以打赌，LSASS.exe系统错误或失败是最常见且对该环境有最大影响。因此，活动目录管理员和支持人员理解LSASS的工作及故障排解的途径非常重要。

　　LSASS是什么？

　　LSASS.exe主要任务是处理认证请求并允许或拒绝对用户请求的访问。这些请求来自于域登录尝试或是回答用户请求的其它服务或应用。在所有事件中，如果LSASS不及时处理请求，该请求可能失败或者长时间推后。

　　LSASS.exe主要消耗每个域控制器上的内存和CPU资源。对这些资源的消耗如果达到某一程度，域控制器可能会：

1. 无法满足其它服务的要求，如活动目录复制。
2. 由于LSASS需要的资源比域控制器可提供的更多，回应认证请求和LDAP搜索的速度变慢。
3. 终止或中断所有服务。

　　这不是一个新问题，微软在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位大型内存平台来向活动目录环境添加更大马力。