www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
Date Wed, 01 Apr 1998 21:20:01 GMT
The following reply was made to PR mod_log-any/2026; it has been noted by GNATS.

From: Marc Slemko <marcs@znep.com>
To: Rob Mela <Rob_Mela@zd.com>
Cc: Apache bugs database <apbugs@apache.org>
Subject: Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes
Date: Wed, 1 Apr 1998 14:13:26 -0700 (MST)

 On Wed, 1 Apr 1998, Rob Mela wrote:
 > I am using my own log format, and I'm pretty sure it is longer than the
 > CLF.  I have some options there for saving space.  But, the 2 gig limit was
 > reached after 8 or 9 million hits, which occurred only as a result of one
 > night's log rotation and server restart not running.
 > I'd thought about two things:
 >      - logging to a pipe to gzip or a program that does file rotations
 >      - hacking the log module to log directly to a database
 >      - hacking the log module to do automatic log rotations
 > I'd prefer to avoid pipes or a database.  I see the simplest solutions as
 > the least error-prone and most recoverable --and a direct file write seems
 > the simplest.
 > My first choice is automatic rotations.  Fewer moving parts, and no need to
 > restart the server.  I don't like restarting the server during the day
 > (approx 90 hits per second), since I think a lot of people will be getting
 > timeouts (it takes a minute or two to get up to speed again).
 Rotate your logs more often using SIGUSR1.
 See http://www.apache.org/docs/stopping.html for details.  It doesn't
 cause the same disruption that a HUP does, but it means you have to be
 more careful about touching the old logs afterwards for a while since hits
 will still get written to them for a bit until all the old children exit. 
 1.2.x shouldn't take that long to get up to speed iff your StartServers is
 high enough; if not, then it will because it will only start a new process
 once every second.  1.3 does exponential spawning, so behaves much better
 under such situations.
 There is a rotatelogs in the support directory that can run from a pipe,
 but it looks a bit pokey for high volumes and you still have potential
 issues with piped logs and 1.2.  In 1.3, using piped logs is really a very
 good solution and is very reliable and flexible.

View raw message