Bug #5181
closed
nscd is extremely slow when a local file is missing
100%
Description
In a case the files source is configured in nsswitch.conf and the particular local file is missing, the nscd could spent a lot of time (10 seconds) trying to access such missing file. The nscd is basically waiting here in _nss_files_XY_hash():
406 retries = 100;
407 while (stat64(be->filename, &st) < 0) {
408 /*
409 * On a healthy system this can't happen except during brief
410 * periods when the file is being modified/renamed. Keep
411 * trying until things settle down, but eventually give up.
412 */
413 if (--retries == 0)
414 goto unavail;
415 poll(0, 0, 100);
416 }
Steps to reproduce the problem:
# mv /etc/group /etc/group.orig # svcadm restart svc:/system/name-service-cache:default # time getent group adm real 0m9.927s user 0m0.001s sys 0m0.003s # mv /etc/group.orig /etc/group # time getent group adm adm::4:root,daemon real 0m0.002s user 0m0.000s sys 0m0.001s #
In a case the particular file (the /etc/group file in the case above) does not exist at all we should fail immediately.
Updated by Rich Lowe about 7 years ago
Out of interest, in the unlikely event someone does have a system whereby updates to database files remove them briefly (I sure hope they don't, that'd be terrible), will we negative cache anything queried during the period they're absent?
I guess I'm trying to guess why in the world someone did this in the first place, though I don't really think it matters.
Updated by Marcel Telka about 7 years ago
Rich Lowe wrote:
Out of interest, in the unlikely event someone does have a system whereby updates to database files remove them briefly (I sure hope they don't, that'd be terrible), will we negative cache anything queried during the period they're absent?
No. We will wait (up to 10 seconds) until the file reappears. If the file is still not there, even after 10 seconds, we will fail, but nothing is cached. On new request, we try again to access the file. If the file is still not there, we will fail immediately (and again, nothing is cached).
I guess I'm trying to guess why in the world someone did this in the first place, though I don't really think it matters.
Apparently, there was some reason for that when it was implemented. I assume there existed (or still exists?) some scenario used by somebody where the file could disappear for short time. I preserved this (a bit strange) behavior, so everybody should be happy :-).
Updated by Marcel Telka about 7 years ago
- Subject changed from nscd is extremely slow when a local file is missing to nscd is extremely slow when a local file is missing
Updated by Marcel Telka about 7 years ago
- Status changed from In Progress to Pending RTI
Updated by Electric Monk about 7 years ago
- Status changed from Pending RTI to Closed
- % Done changed from 0 to 100
git commit 655967ab7780f789dd00eece4464be60cd9aff5e
commit 655967ab7780f789dd00eece4464be60cd9aff5e
Author: Marcel Telka <marcel.telka@nexenta.com>
Date: 2014-09-18T23:01:17.000Z
5181 nscd is extremely slow when a local file is missing
Reviewed by: Alek Pinchuk <alek.pinchuk@nexenta.com>
Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
Reviewed by: Josef Sipek <josef.sipek@nexenta.com>
Reviewed by: Garrett D'Amore <garrett@damore.org>
Approved by: Robert Mustacchi <rm@joyent.com>