9:14 a.m.
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
--
Olaf Gellert email gellert(a)dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 460094 214
Bundesstrasse 45a fax +49 (0)40 460094 270
D-20146 Hamburg, Germany www http://www.dkrz.de
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Prof. Dr. Thomas Ludwig
Registergericht: Amtsgericht Hamburg, HRB 39784
10:39 a.m.
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..
9:16 a.m.
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?
9:54 a.m.
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:
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.
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
--
Olaf Gellert email gellert(a)dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 460094 214
Bundesstrasse 45a fax +49 (0)40 460094 270
D-20146 Hamburg, Germany www http://www.dkrz.de
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Prof. Dr. Thomas Ludwig
Registergericht: Amtsgericht Hamburg, HRB 39784
4286
days inactive
4291
days old
sssd-users@lists.fedorahosted.org
3 comments
3 participants
participants (3)
-
Jakub Hrozek -
Olaf Gellert -
Stephen Gallagher