From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17372 invoked by alias); 31 Oct 2013 05:13:26 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 17320 invoked by uid 48); 31 Oct 2013 05:13:21 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nscd/16104] New: nscd statistics are inaccurate when local client searches cache. Date: Thu, 31 Oct 2013 05:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nscd X-Bugzilla-Version: 2.19 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-10/txt/msg00377.txt.bz2 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.