Add Offline Thread Pool Diagnostics design doc#30
Conversation
|
|
||
| ### The status file | ||
|
|
||
| At startup, ns-slapd creates slapd-INSTANCE.threadpool in the server run directory (for example /run/dirsrv/slapd-localhost.threadpool). The file starts with a 4KB header followed by one 64 byte slot per worker thread. The layout is defined in ldap/servers/slapd/threadpool_stats.h, and the lib389 reader mirrors the same field list. |
There was a problem hiding this comment.
This allows to monitor the instance without the need of LDAP operations. Here it is the threadpool. We can imagine others monitoring backtraces, connections,...
About putting the mapped files under a common monitoring directory like
/run/dirsrv/slapd-localhost.monitor/threadpool
/run/dirsrv/slapd-localhost.monitor/backtraces
/run/dirsrv/slapd-localhost.monitor/connections
...
There was a problem hiding this comment.
Good call!
Ok, I implemented this in the feature PR. The files now go under /run/dirsrv/slapd-localhost.monitor/* as threadpool files, so future diagnostics can live alongside it.
|
|
||
| ### Writing the data | ||
|
|
||
| The pool gauges already exist as internal counters. Once per second, a callback on the event queue thread copies them into the header and updates the heartbeat timestamp. The event queue thread is not a worker thread, so the heartbeat keeps running when all the workers are busy. When the whole process stops making progress, the heartbeat stops updating, and the reader uses that to warn that the server may be stalled. |
There was a problem hiding this comment.
In case those mapped files are grabbed by sosreport tool, we would need to be able to read them with other versions of dsctl than the one installed. Do you think we would need a version number in the mapped files ?
There was a problem hiding this comment.
Yep, already there! The header has a format version, magic value, and size fields that the reader validates before parsing. I updated the design doc to describe this in detail.
No description provided.