(no subject)

[theweaselking]

No, the last 31 days of logs should probably not be 17GB. And growing at about 3MB/hour. Why do you ask?

Comments

[sanityimpaired.livejournal.com]

*Collapses laughing*

[theweaselking.livejournal.com]

Yeah. At the current rate, that mail server will run out of disk space in, like, 35 years!

(A bug in the server software meant "Log rotation" went horribly wrong, so every day a new "message traffic" logger process would spawn and being dumping logs into the database. The database, now being fed a plethora of complete crap, gained a 100% useless 100% corrupt "raw logs" table - but it was a very large one!

Loggers have been killed. Stupid bug has been killed. Table repair underway, logging will resume probably sometime Monday. Bonus points: the actual log in question isn't errors or message traffic or authentication or anything. No, the busted log process simply records *how many messages go through the server*, nothing else. All the other logs are working fine.)

[sanityimpaired.livejournal.com]

As long as the log itself is obviously bunk and doesn't have to be read in detail. 17 GB of plain text reading - *Boggle*

[theweaselking.livejournal.com]

That's why Larry Wall invented *perl*.

(But seriously: once the table is legible, the software should be able to trash it down to a much more reasonable 200MB or so, which will let the scripts for the reports and the prettty graphs work properly. And, if not, it's the MESSAGE TRAFFIC LOG. "truncate raw_logs;" and let the garbage collector sort it out.)

[jerril]

What I love is how we keep getting nagged for "Filling up the backup tape" and how we need to delete everything...

[theweaselking.livejournal.com]

Your department is using way more than your share. This is just, uh, a different problem. That's not actually included in the backups.

(any more)