httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: ETags & NFS caches (Apache 1.3)
Date Fri, 27 Oct 2000 15:22:40 GMT
On Fri, 27 Oct 2000, Thomas Wouters wrote:
> The problem isn't load on the filer. In fact, the load on the filer is
> extraordinarly low :) We've done some brutal assault as well, when we had
> both our mailspool and our home directories on the same F720, which would
> then crap out when we started running 'dump' remotely, but never saw
> something like this. And the filer we are using for is an
> older F330 that does little else. If the problem is the filer, which is
> still possible, it's probably caused by the huge number of requests for a
> limited number of files.... or something. None of the less frequently
> accessed files show this problem, even though 'less frequently' here is
> still a respectable frequency for any website :)

What kind of traffic is it, BTW, and what % is static?

> (The low load on the F330 is a clear indication that BSDI is doing massive
> caching, though. The weird thing remains that Apache doesn't see a change
> until some other process accesses the file. Really strange.)

Actually, that pretty much fits it being a cache: if a fresh open() call
(i.e. from a process which hasn't touched the file before) causes BSDI to
revalidate the request, but it skips that stage for Apache (since it
accessed the file very recently)...

> > Another possibility: is the OS skipping the open() call from Apache (since
> > the file was just opened), but handling it properly when another process
> > makes it? Remember access control checks etc. are made on open(); if BSDI
> > were wrongly caching this for repeated open() calls from a single process,
> > that could explain the problem.
> Yes. I'm going to install the weak etag thing today, just so the site can
> function a tad better, and then do some things like running ktrace on an
> apache process (ktrace is BSDI's form of strace, but less useful), trying to
> grok BSDI kernel and libc code, and trying to reproduce it on another box,
> by doing all the requests ourselves. Not being able to test except on the
> main pages on a high-profile site doesn't really help at debugging :)

Indeed. Is is a straight Apache set up, BTW, or do you have something like
a Squid accelerator in front of it?

One thing I would try is setting the mount option "noac" or "actimeo=0"
(or the BSDI equivalent) - disable attribute caching entirely. This should
avoid out-of-date mtimes. Have you tried enabling synchronous read/write
access (option "sync")?

This would probably kill performance - having Squid on each machine, using
a local disk, should help reduce this effect again.

> [ weak etags might fix things ]
> > While it would be nice (for you) to avoid the problem like that, getting
> > Apache (or BSDI??) fixed properly would be preferable IMO :-)
> Of course, but I doubt it's something Apache can fix, without creating
> digests for every single request. I'm thinking it's flawed logic in the BSDI
> libc, something like 
>     if file in fd_cache and last_access(file) < 100ns_ago:
>         last_access(file) = now
>         return fd_cache[file]
> but which somehow only gets triggered in severe edge cases. Don't ask me why
> it isn't showing in anything but apache, though :-)

Hrmm..... It could well be an OS "optimisation" for a file opening and
closing a single file repeatedly (as a mail client could, for example)...


View raw message