ad ds核心吞吐能力由ldap、ese数据库、复制及系统资源四类计数器协同体现：ldap层看searches/sec、bind time与client sessions；ese层看缓存命中率与页错误率；复制层看pending operations与gc搜索率；系统层看cpu队列、线程池占用及kerberos认证速率。
ad ds 的核心吞吐量不是单个“吞吐量”数值，而是由多个关键计数器协同反映的综合能力，重点看单位时间内完成的有效目录操作及其响应效率。监控时不能只盯总量，要区分速率类、延迟类和资源支撑类指标，并结合业务场景判断是否真有瓶颈。
LDAP 协议层吞吐与响应能力
这是用户登录、组策略获取、DNS 记录查询等动作最直接依赖的路径：
-
NTDS\LDAP Searches/sec：每秒成功执行的 LDAP 查询数。工作时间持续低于基线（如比前7天均值低40%）且伴随 NTDS\LDAP Search Time (msec) 升高，说明查询效率下降，可能因索引缺失或筛选器过宽（如
(objectClass=*)） - NTDS\LDAP Bind Time：平均绑定耗时。正常应稳定在 100ms，即使搜索量不高，也意味着 Kerberos 验证、证书检查或网络握手环节已拖慢首字节响应，直接影响登录速度
- NTDS\LDAP Client Sessions：活跃会话数。长期 >500 并伴随 NTDS\Threads in Thread Pool 接近上限，大概率是客户端未释放连接（如老旧脚本、未关闭的管理工具），造成会话堆积而非真实负载上升
数据库引擎（ESE）实际处理吞吐
NTDS 数据库存取效率决定了所有读写操作的底层能力，吞吐瓶颈常藏在这里：
- NTDS\DS Database Cache % Hit：缓存命中率。低于 95% 意味着大量查询被迫落盘，需交叉查看 PhysicalDisk\Avg. Disk sec/Read 是否 >20ms —— 若是，说明磁盘 I/O 成为吞吐瓶颈
- NTDS\DS Database Page Faults/sec：页错误率。持续 >100 表明 ESE 缓存不足（默认最多使用约 80% 物理内存），系统频繁换页，直接压制吞吐潜力；此时 Memory\Available MBytes 往往已
- NTDS\DS Search Time (msec) 要结合 NTDS\LDAP Searches/sec 看：高搜索量下毫秒值稳定，说明吞吐健康；若搜索量中等但毫秒值飙升，才是数据库层真实压力信号
复制与全局编录（GC）的跨域吞吐保障
多域控环境下，GC 查询和复制同步是跨域登录、UPN 解析、Exchange 地址簿等服务的吞吐基础：
- NTDS\DRA Inbound Bytes Total/sec 和 NTDS\DRA Outbound Bytes Total/sec：反映实时复制流量。连续 5 分钟无增长，或突降 90%，代表某条复制链路中断，后续 GC 内容将陈旧，导致跨域对象查找变慢甚至失败
- NTDS\Replication Pending Operations：待同步操作数。>100 是明确预警信号，说明 DC 已积压大量变更未应用，组策略更新、密码修改等将延迟生效
- NTDS\GC Search Rate (searches/sec)（若启用 GC）：GC 查询频率。配合 NTDS\GC Name Cache % Hit（建议 >90%）看，若查询量高但缓存命中率低，GC 响应吞吐会急剧下降，影响 Exchange 和 Teams 等依赖 GC 的应用
配套系统资源吞吐支撑能力
再好的 AD DS 配置，也会被底层资源卡住。这些计数器不直接叫“吞吐”，但决定吞吐能否持续输出：
- Processor(_Total)\% Processor Time 与 System\Processor Queue Length：CPU 使用率不高（2，说明线程在等锁或 I/O，不是算力问题，而是协调或存储拖慢了整体吞吐节奏
- NTDS\Threads in Thread Pool：工作线程占用率。长期 >85%（如 64 线程池占满 55+），说明请求排队，哪怕 CPU 和磁盘都空闲，吞吐也上不去
- Security System-Wide Statistics\Kerberos Authentications/sec：真实认证吞吐量。若该值突降至接近 0，而其他 LDAP 计数器仍有活动，说明 Kerberos 票据分发已瘫痪，整个身份验证吞吐归零
