nisplusLDAPentryTtl 属性

由于 rpc.nisd 守护进程的本地数据库（位于内存中和磁盘上）充当 LDAP 数据的高速缓存，因此可使用 nisplusLDAPentryTtl 属性来设置该高速缓存中各项的生存时间 (time-to-live, TTL) 值。每个数据库 ID 都有三个 TTL。前两个 TTL 用于控制当 rpc.nisd 首次从磁盘中装入对应的 NIS+ 对象数据时的初始 TTL，第三个 TTL 将在从 LDAP 中读取或刷新对象时指定给该对象。

例如，通过以下语句，rpc.org_dir 表对象可获取在 21600 秒到 43200 秒的范围内随机选择的初始 TTL。

nisplusLDAPentryTtl	rpc_table:21600:43200:43200

如果初始 TTL 过期并从 LDAP 中刷新了表对象，则该 TTL 将设置为 43200 秒。

同样，使用以下语句，可在首次装入 rpc.org_dir 表时向该表中的各项指定介于 1800 秒和 3600 秒之间的初始 TTL。

nisplusLDAPentryTtl	rpc:1800:3600:3600

每项都会获取各自在指定范围内随机选择的 TTL。如果某个表项过期并已刷新，则该 TTL 将设置为 3600 秒。

选择 TTL 值时，需要综合考虑性能和一致性。如果由 rpc.nisd 高速缓存的 LDAP 数据所使用的 TTL 非常长，则性能与 rpc.nisd 根本未从 LDAP 映射数据时一样。但是，如果 LDAP 数据被 rpc.nisd 以外的某个实体更改，则所做的更改也可能会在很长时间之后才显示在 NIS+ 中。

相反，如果选择非常短（或者甚至为零）的 TTL，则意味着对 LDAP 数据进行的更改会迅速显示在 NIS+ 中，但这也可能会大大降低性能。通常，对于会同时从 LDAP 中读取数据或向 LDAP 中写入数据的 NIS+ 操作而言，所需的时间将至少为没有 LDAP 通信时执行同一操作所需时间的两到三倍（而且还会带来额外的 LDAP 查找开销）。尽管性能会因为硬件资源而大不相同，但是，扫描大型 LDAP 容器（具有几万或几十万个项）以确定应当刷新的 NIS+ 项可能会需要很长时间。rpc.nisd 守护进程在后台执行扫描操作，从而可在运行时继续为可能过时的数据提供服务，但是后台扫描仍然会占用 NIS+ 服务器中的 CPU 和内存。

请仔细考虑保持 NIS+ 数据与 LDAP 密切同步的重要性，并选择每个 NIS+ 对象都可接受的最长 TTL。缺省值（未指定 nisplusLDAPentryTtl 时的值）是 1 小时。对于表项以外的对象，模板映射文件 /var/nis/NIS+LDAPmapping.template 会将该值更改为 12 小时。但是，系统无法自动识别非项对象，因此，如果要为非项对象添加映射，TTL 的缺省值将为 1 小时。

不存在的对象没有 TTL。因此，无论哪些 TTL 对于 NIS+ 表中的 LDAP 映射项有效，对于 NIS+ 中不存在的项发出请求时都将在 LDAP 中查询该项。