cn=Directory Manager
All about Directory Server
All | Personal | Sun

20060728 Friday July 28, 2006

Understanding the Backend Monitor Entries

Earlier, I wrote about the cn=monitor entry and the kinds of information that it provides. I mentioned in passing that the backendMonitorDN attribute specifies the DNs of the monitor entries for the backends defined in the server, but I didn't go into any detail on what data they provided. There is a lot of useful information in the backend monitor entries, and they deserve their own post to describe their content.

The backend monitor entries have a DN of "cn=monitor,cn={backendID},cn=ldbm database,cn=plugins,cn=config", where "{backendID}" is the name of the backend you're interested in monitoring (e.g., "userRoot" is the name for the default backend when a new instance is created). The monitor entry provides information specific to that backend, including cache and database statistics. The attributes in these entries include:
  • currentEntryCacheCount -- This specifies the number of entries that are currently held in the entry cache for the backend.

  • currentEntryCacheSize -- This specifies the amount of memory (in bytes) that the server believes the backend's entry cache is consuming. This number may be somewhat inaccurate (see my earlier post on cache sizing for why this is the case), although the accuracy should be improved in the upcoming Directory Server 6 release.

  • database -- This specifies the type of database that is in use for the backend. This should always be "ldbm database".

  • dbEntryCount -- This specifies the number of entries in the backend database (i.e., the number of unique keys in the id2entry database file).

  • dbFileCacheHit-# -- This specifies the number of times the server requested an entry from the associated database file and the data was already contained in the database cache.

  • dbFileCacheMiss-# -- This specifies the number of times the server requested an entry from the associated database file and the data was not contained in the database cache.

  • dbFileName-# -- This specifies the path to a database file for the backend. Note that the "-#" part of this and other dbFile* attribute names actually indicates an integer value. Each database file accessed by the server will be given a different number, and the same number will be used for the DB file name, hit and miss count, and page in and out count so that those statistics can be associated with the appropriate database file.

  • dbFilePageIn-# -- This specifies the number of times that content from the associated database file had to be paged into the cache.

  • dbFilePageOut-# -- This specifies the number of times that content from the associated database file was paged out of the cache (presumably to make room in the cache for another database page that needed to be paged in).

  • entryCacheHitRatio -- This specifies the percentage of the time that a request to retrieve an entry from the entry cache actually finds that entry in the cache. It will be equal to 100 * entryCacheHits / entryCacheTries.

  • entryCacheHits -- This specifies the total number of times that a request to retrieve an entry from the entry cache actually finds that entry in the cache.

  • entryCacheTries -- This specifies the total number of times that a request was made to retrieve an entry from the entry cache, regardless of whether or not the target entry was in the cache.

  • ldapEntryCount -- This specifies the number of LDAP entries in the backend database. The difference between this and the dbEntryCount attribute is that the ldapEntryCount does not include special entries like tombstones that are not generally accessible over LDAP.

  • maxEntryCacheCount -- This specifies the maximum number of entries that may be held in the entry cache, or -1 if there is no upper limit to the number of entries to store.

  • maxEntryCacheSize -- This specifies the maximum amount of memory in bytes that the server will try to use for the entry cache. Again, this may be a little inaccurate, but Directory Server 6 should be better than 5.2 in this area.

  • nextID -- This specifies the entry ID that will be used for the next entry that is added to the backend database. This is generally not that useful for monitoring, but may be helpful for some corner cases when debugging problems.

  • readOnly -- This indicates whether the backend is configured to be read-only. Note that even if the backend itself is not configured in read-only mode, the server-wide read-only configuration may be enabled which has the same effect but across all backends.

Posted by cn_equals_directory_manager ( Jul 28 2006, 05:29:08 PM CDT ) Permalink


Archives
Language
Links
Referrers