What part of your webserver is even doing DNS lookups? Most webserver configurations explicitly disable reverse DNS lookup of each incoming user, for speed (because DNS is slow in general).
As Patrick notes, nscd is doing the right thing and respecting the positive TTL values. Yes, you could override it (unbound would let you do this easily, just modify server.cache-min-ttl, has warnings about increasing it beyond 1 hour for the same reasons). HOWEVER, your queries are probably mostly rDNS, which will tend to have longer TTLs in general.
Additionally, since your maximum number of cached values is so low, I'd like to note that you're hardly getting any traffic.
If you do care about where you users repeat from that often, I'd suggest logging it outside nscd, and not worrying about it anymore.
Edit (2013/12//09):
nscd -g hosts stats from dev.gentoo.org (no blocks in comments):
nscd configuration:
4h 8m 43s server runtime
hosts cache:
yes cache is enabled
no cache is persistent
no cache is shared
422 suggested size
1108744 total data pool size
966632 used data pool size
600 seconds time to live for positive entries
20 seconds time to live for negative entries
67878 cache hits on positive entries
2479 cache hits on negative entries
9464 cache misses on positive entries
4276 cache misses on negative entries
83% cache hit rate
6951 current number of cached values
7641 maximum number of cached values
33 maximum chain length searched
1 number of delays on rdlock
0 number of delays on wrlock
0 memory allocations failed
yes check /etc/hosts for changes
It is not clear if you search for page in/out caused by paging or by swapping. The difference is explained at several places here (https://superuser.com/questions/785447). The number of pages swapped and paged from /proc/vmstat.
Pages paged in / out
$ cat /proc/vmstat|grep pgpg
pgpgin 6920262
pgpgout 345654122
Pages swapped in / out
$ cat /proc/vmstat|grep pswp
pswpin 0
pswpout 0
Best Answer
You cannot have the kernel only inform you of a change to a certain path. The reasons are a bit subtle:
In Linux, a file object exists independently of any name(s) it may have. Files' names are actually attributes of their containing directory, and a single file may be called by multiple names (see, hardlinking).
The kernel has to have something to attach inotify objects to; it cannot attach an object to a pathname since a pathname isn't a real filesystem object; you have to attach to the parent directory or the file that path describes. But you can't attach to the file, because you're watching to see if a file with a given name is created, not changes to a given file.
Theoretically, the kernel could implement an API that allows you to select events for a given pathname when adding a watch to a directory, much in the same way it allows you to select types of events. This would bloat the API, and the kernel would in the end be processing the same data and doing the same string comparison you would be doing in userspace.
Is there a noticeable performance hit to placing a watch on a very active directory? I'm not sure how active you mean; tens of files a second, hundreds, millions?
In any case, I would avoid
access: it's always going to be racey. A file could be created and removed between calls toaccess, and callingaccessin a very tight loop is going to be slow, and is the kind of probleminotifywas designed to solve.