This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nscd/16104] New: nscd statistics are inaccurate when local client searches cache.
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 31 Oct 2013 05:13:19 +0000
- Subject: [Bug nscd/16104] New: nscd statistics are inaccurate when local client searches cache.
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16104
Bug ID: 16104
Summary: nscd statistics are inaccurate when local client
searches cache.
Product: glibc
Version: 2.19
Status: NEW
Severity: normal
Priority: P2
Component: nscd
Assignee: unassigned at sourceware dot org
Reporter: carlos at redhat dot com
CC: drepper.fsp at gmail dot com
A local client making use of nscd may request via GETFDPW, GETFDGR, GETFDHST,
GETFDSERV, or GETFDNETGR that an mmap-able fd of the entire cache be made
available such that that client can search the cache itself.
This behaviour is the fast path and allows the client to offload some
processing from the server process to the client process, and is in general
faster than waiting for an nscd worker thread to complete the lookup.
The problem is that if a positive hit or negative hit is found in the cache
there is no way to update the server statistics on the successful hit and
therefore in some cases the server statistics are completely inaccurate.
I do not suggest that we slow down the fast path, but the server did receive
one of the GETFD* request packets and therefore should have been able to record
receiving one of those and display that as a statistic.
I propose we display:
%d number of client-side cache searches
This way if you run `getent netgroup foo' in a loop you will at least see this
statistic incrementing showing that the client's are doing all the lookups.
Obviously a failed search via the client of the memory mapped cache means that
the client must fall back on having nscd do the actual lookup and that will
show up in the statistics (usually as a positive cache miss).
--
You are receiving this mail because:
You are on the CC list for the bug.