|
| Sun ONE Directory Server 5.2 安装和调整指南 |
Directory Server 将目录信息缓存到内存中或磁盘上，以便能够更快地对客户机请求作出响应。正确调整的缓存能够将处理客户机请求时对访问磁盘子系统的要求降至最低。
注意 除非正确调整缓存且工作正常，否则其他的调整可能仅会对性能产生有限的影响。
缓存类型
Directory Server 处理三种类型的缓存，如表 6-1 中所述。
表 6-1 缓存
缓存类型
说明
数据库
每个 Directory Server 实例具有一个数据库缓存，以数据库格式存放索引和条目。
条目
每个后缀具有一个条目缓存，存放早先操作过程中从数据库检索到的条目，并将其格式化以便快速发送给客户机应用程序。
导入
每个 Directory Server 实例具有一个与数据库结构相似的导入缓存，在批量加载过程中使用。
Directory Server 也受益于基础操作系统处理的文件系统缓存，以及磁盘子系统中的 I/O 缓冲区。
图 6-1 显示了 Directory Server 处理三个后缀（每个后缀具有其自己的条目缓存）实例的缓存。将该实例配置为处理大量磁盘活动，并如第 8 章“调整日志记录”中所建议的那样将事务日志、数据库以及其他文件和日志置于单独的磁盘子系统上。
图 6-1 环境中的条目和数据库缓存
数据库缓存
每个 Directory Server 实例具有一个数据库缓存。数据库缓存可存放页面，此页面来自包含索引和条目的数据库。每页不是一个条目，而是包含部分数据库的内存扇区。指定数据库缓存大小 (nsslapd-dbcachesize)。对数据库缓存大小所作的更改在重新启动服务器以后生效，且服务器启动时分配数据库缓存空间。
Directory Server 在数据库文件和数据库缓存之间移动页面以保持最大数据库缓存容量。由于需要额外的内存来管理数据库缓存自身，因此 Directory Server 实际使用的内存数量可能多于指定的容量，达到 25%。
当使用容量极大的数据库缓存时，请在 Solaris 系统上凭经验测试和使用诸如 pmap(1) 的工具监视内存使用情况，确认 Directory Server 使用的内存没有超出可用物理内存的大小。超出可用物理内存造成系统重复地分页，导致性能严重降低。
也可将 Directory Server 支持的 ps(1) 公用程序（位于 UNIX 平台上）与 -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 如何处理指定基本 DN 的搜索和使用过滤器的搜索。单独的线代表访问不同级别内存的线程，断开的线代表通过有效调整减少的步骤。
图 6-2 搜索和缓存
基本搜索处理
如上所示，基本搜索（指定基本 DN 的搜索）是 Directory Server 处理的最简单的搜索类型。要处理此类搜索，Directory Server：
- 尝试从条目缓存检索具有指定基本 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：
- 执行基本 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 系统上使用诸如 iostat(1M) 的公用程序以隔离潜在的 I/O 瓶颈。有关处理 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 文档。可以按“下载 Directory Server 工具”中所述获得 Sun ONE Directory Server Resource Kit。
在填充了其他缓存后，可以填充可用的文件系统缓存。尽管无法保证文件系统缓存中的信息未被刷新，但填充文件系统缓存仍可提升发生剧烈变化的时间。要在 UNIX 系统上填充文件系统缓存，可作为超级用户使用 dd(1M) 命令。在 Solaris 系统上数据库文件位于默认位置，例如：
# for db in ServerRoot/slapd-serverID/db/*/*.db3
> do
> dd if='pwd'/$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) 中的大小应该等于或非常接近于后缀中条目的总数。
其他优化
调整缓存大小仅代表改进搜索、更新或批量加载率的方法之一。随着对缓存进行调整，缓存的性能瓶颈转移到系统的其他部分。详细信息，请参阅本指南中的其他章节。