Hi there,
is there anything in place to get statistics of the cache usage of sssd? With "nscd" you could run "nscd -g" to get this, would be a nice feature. Did not find anything in the man pages nor any extra tool or command line option.
Olaf
On Thu, Jul 26, 2012 at 04:14:21PM +0200, Olaf Gellert wrote:
Hi there,
is there anything in place to get statistics of the cache usage of sssd? With "nscd" you could run "nscd -g" to get this, would be a nice feature. Did not find anything in the man pages nor any extra tool or command line option.
Olaf
No, we currently don't have any such feature. Feel free to file an RFE.
Some data could be mined with a script from the NSS logs, I guess..
On Thu, 2012-07-26 at 17:39 +0200, Jakub Hrozek wrote:
On Thu, Jul 26, 2012 at 04:14:21PM +0200, Olaf Gellert wrote:
Hi there,
is there anything in place to get statistics of the cache usage of sssd? With "nscd" you could run "nscd -g" to get this, would be a nice feature. Did not find anything in the man pages nor any extra tool or command line option.
Olaf
No, we currently don't have any such feature. Feel free to file an RFE.
Some data could be mined with a script from the NSS logs, I guess..
This has been discussed before, but we're not currently planning on implementing it. There are several reasons for this: 1. Modern SSSD implementations actually have two caches, one in shared memory and another provided by the NSS responder. So we would somehow need to maintain both of them in this option. 2. It would be an unnecessary performance hit to do a write() for every read() of the cache.
The best we can realistically do here I think would be to provide a log of cache-misses. So only on those cases where we actually go out to the ID provider to refresh the cache should be logged and stored. I'm not really sure what value this information provides though.
Olaf, perhaps you could describe what information you want to see and how you intend to use it?
Hi again,
Stephen Gallagher wrote:
This has been discussed before, but we're not currently planning on implementing it. There are several reasons for this:
- Modern SSSD implementations actually have two caches, one in shared
memory and another provided by the NSS responder. So we would somehow need to maintain both of them in this option. 2. It would be an unnecessary performance hit to do a write() for every read() of the cache.
The best we can realistically do here I think would be to provide a log of cache-misses. So only on those cases where we actually go out to the ID provider to refresh the cache should be logged and stored. I'm not really sure what value this information provides though.
I was just looking for something to get a feeling of the efficiency of the caching. I was not thinking about writing stuff to logfiles (that would mean too much IO), more like keeping the statistics in memory and a tool that contacts the daemon, gets the stuff and prints it to stdout.
Anyway, it is not THAT important, we already collect information about how many queries each LDAP client sends, so we see the end result. In case of "nscd" it is always a good idea to have a look if it still works, I guess (and hope) SSSD is much more stable.
Olaf
sssd-users@lists.fedorahosted.org