
Thursday July 27, 2006
Understanding the cn=monitor entry
The Directory Server's "cn=monitor" entry provides a means of gaining insight into what's going on inside the server. However, there may be attributes in this entry with names that don't clearly explain what kind of information they provide. In this post, I'll try to shed some light on them.
The attributes contained in this entry include:
- backendMonitorDN -- This specifies the DNs of the monitor entries for each of the backends in the server. The backend monitor entries provide details about the server's interaction with the backend databases. The contents of these entries could easily constitute a separate post.
- bytesSent -- This specifies the total number of data bytes included in the responses that it has sent to clients. Note that this only includes data bytes and does not include packet headers (e.g., link-level, IP, and TCP headers).
- cache-avail-bytes -- This specifies the amount of free memory in the system that could possibly be using for caching. Note that it does *not* specify how much of the cache is unused like one might think. Honestly, it's not all that useful.
- connection -- This is a multivalued attribute with a separate line per established connection. This attribute will only appear if the monitor entry is retrieved by the root DN (e.g., "cn=Directory Manager"). Values are constructed in a colon-delimited form with the following components:
- The slot in the connection table, which generally equals the file descriptor number
- A timestamp that specifies when the connection was established (in UTC)
- The number of operations initiated on the connection
- The number of operations completed on the connection
- If the connection is in the process of reading data from the client, then the letter "r". Otherwise, it will be blank
- The DN of the authenticated user for the connection
- The protocol the client is using to communicate with the server
- connectionPeak -- This specifies the maximum number of concurrent connections that have been established to the server at any given time.
- currentConnections -- This specifies the number of connections that are currently established to the server.
- currentTime -- This specifies the current time according to the system clock on the server (in UTC).
- dTableSize -- This specifies the size of the file descriptor table for the server. This should be equal to the value of the nsslapd-maxdescriptors configuration attribute.
- entriesSent -- This specifies the total number of search result entries sent to clients in response to search requests.
- heapMaxHighHits -- This specifies the number of times that the server heap has grown large enough that it was necessary to free entries in the cache while holding an exclusive lock on the cache. Having this value increase is less desirable than having the heapMaxLowHits value increase, because it can have a significant impact on performance.
- heapMaxLowHits -- This specifies the number of times that the server heap has grown large enough that it was necessary to free entries in the cache, but without the need to lock the entire cache. This will have a lesser impact on performance than cases in which it is necessary to hold the lock while freeing entries.
- nBackends -- This specifies the number of backends (also called databases) configured in the server.
- opsCompleted -- This specifies the total number of operations that have completed processing since the server started. The difference between opsInitiated and opsCompleted should equal the number of operations in progress.
- opsInitiated -- This specifies the total number of operations that have been initiated since the server started.
- readWaiters -- This specifies the total number of client connections for which the Directory Server is waiting to read more data from the client (i.e., the client has started sending a request but has not yet completed it). This should be equal to the number of connections with the "r" notation in the connection attribute.
- request-que-backlog -- This specifies the number of requests that are currently sitting in the work queue waiting to be picked up by a worker thread. Having more than a couple of requests sitting in the work queue at any given time generally isn't a good thing because it means that all of the worker threads are busy processing other requests so new requests have to wait.
- startTime -- This specifies the time that the server was started (in UTC time).
- threads -- This specifies the number of worker threads currently configured for use in the server (as controlled by the nsslapd-threadnumber configuration attribute).
- version -- This is the Directory Server version string. It can be altered to an extent via the nsslapd-versionstring configuration attribute to help it deal with clients that foolishly are hard-coded to only work with a specific server version, but in general changing that string is not recommended.
I'd say that the most important thing to watch here is the request-que-backlog attribute, since the higher it is the more requests are having to wait in the queue before they can be processed. If you consistently see currentConnections growing over time, then that could indicate that one or more of your clients aren't properly closing their connections when they're done with them, and if it gets too close to the dTableSize value (and in particular, dTableSize minus the value of nsslapd-reserveDescriptors) then the server could start rejecting new connections.
Posted by cn_equals_directory_manager
( Jul 27 2006, 08:54:32 AM CDT )
Permalink
|
|
| Archives |
|
|
| « December 2009 | | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | | | | | | Today |
|
|
|
|
|
|
| Language |
|
|
|
|
|
| Links |
|
|
|
|
|
| Referrers |
|
|
|
Today's Page Hits: 225
|
|
|
|
|
|
Posted by KG on July 27, 2006 at 10:04 AM CDT #
Posted by Vijay Trambadia on July 31, 2006 at 12:54 PM CDT #
Fortunately, this licensing model never saw the light of day, but the connectionPeak behavior that was added to support it still exists.
Posted by Neil Wilson on July 31, 2006 at 02:06 PM CDT #