Oh hey just a note for whoever fixes this ... the squid folks (I think) found that trunc()ing dead files and reusing them for later data was way faster than doing an unlink()/open(). I don't know if that's easily done in our code or not.
Dean On Mon, 23 Jun 1997, Henrik Storner wrote: > > >Number: 771 > >Category: mod_proxy > >Synopsis: tmpXXXXX files left behind in top-level proxy-cache directory > >Confidential: no > >Severity: critical > >Priority: medium > >Responsible: apache (Apache HTTP Project) > >State: open > >Class: sw-bug > >Submitter-Id: apache > >Arrival-Date: Mon Jun 23 00:50:01 1997 > >Originator: [EMAIL PROTECTED] > >Organization: > apache > >Release: 1.2.0 > >Environment: > UnixWare 2.03 > uname -a: UNIX_SV olicom 4.2MP 2.03 i386 x86at > gcc 2.7.2 > >Description: > The top-level proxy cache directory gets filled with files named tmp?????? > when running for a period of time. With a couple of thousand files in this > directory, the proxy slows down tremendously. > > This appears to have been reported previously (PR 687 refers to 1.2b11 on > AIX), > but is still present in 1.2.0. Proxy cache directory does have owner/group > set to the owner/group of the httpd proces, as mentioned in PR 687. > >How-To-Repeat: > It seems to happen mostly if the proxy request fails for some reason > (connection timeout, client aborting request etc.) > >Fix: > To alleviate the problem, I added a simple hack to > src/modules/proxy/proxy_cache.c > so it remembers the name of the last tmp* file it created, and unlink's it > just > before creating the next tmp* file. This appears to reduce the number of tmp* > files left behind, but a few are still there - probably due to the process > being > reaped when idle, and not deleting the file in that case. E-mail me if you > want > the diff > >Audit-Trail: > >Unformatted: > > >
