httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@mch.sni.de>
Subject [PATCH] Proxy Garbage Collection fixes
Date Thu, 28 May 1998 11:47:23 GMT
This patch was triggered by a discussion last fall (on this list) about
forking off the garbage collection process of the proxy module.
Dirk-Willem van Gulik proposed a patch, and Dean replied...:

-> Subject: Re: fundamentally wrong forking prior to garbage collection in proxy/
-> In-Reply-To: <Pine.GSO.3.96.971126165553.6555c-100000@elect6.jrc.it>
-> Message-ID: <Pine.LNX.3.95dg3.971127110817.20694B-100000@twinlark.arctic.org>
->
-> I haven't looked to see... but you should fork() twice to disassociate
-> yourself from the child, and the child should wait for the first fork()ed
-> process to return before continuing (otherwise there'll be a zombie).  The
-> whole thing should be inside a block_alarms() and unblock_alarms()
-> section.  And it's probably not something we can do under win32...
->
-> You may even want to setpgrp() after the second fork so that the httpd
-> parent can't send you SIGHUP/USR1/TERM.
->
-> Dean
->
-> On Wed, 26 Nov 1997, Dirk-Willem van Gulik wrote:
-> > Forking off the garbage collecting child in the proxy.
-> >
-> > Anything fundamentally wrong with this quick and dirty hack, it
-> > does seem to work and my my employer happy. But it seems to
-> > crude to me.

This patch addresses these topics.

Furthermore, it contains the following fixes:
*   "real world" operating systems usually allocate files on block
    granularity of 512 bytes or bigger. The old algorithm did not
    account for that, and would think 1023 files with 1 byte each would
    take up less than 1 kB ;-)
    The block size is currently initialized to 512 bytes, but should
    probably be configurable. But with this fix, mod_proxy's idea of
    disk usage is only "10% off" the OS's idea (it used to be >25% off).

*   take into account the non-zero size of directories. These were not
    accounted for in the old code.

*   sensible variable types (size_t, off_t, time_t) where appropriate.

*   avoid use of applying abs() to time_t variables

*   build array of gc_ents, not (gc_ent *)'s

*   "poor man's generalized 61 bit arithmetic" for accumulating
    file's cache size usage

*   At LogLevel debug, GC logs the current cache usage percentage and
    the number of deleted files.

    Martin
-- 
| S I E M E N S |  <Martin.Kraemer@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Mime
View raw message