Messages

Alrighty....
I've cut the logs table by half for now, deleting the data for december last year and january this year (reinder's two busiest months). It's still big (420 MB + 100 Mb Index), but a lot better already. I'll clean out some more months at a later time but want to monitor how things go first. The table was optimized again and everything seems to be running smoothly, as near as I can tell.

The spammers are still at it, with 155 spams from 115 ip's blocked so far today, but these spammers are running into the first defense (which is the least processor hungry) instead of the content-based filters (like the earlier spam attack did).

well I've commented the line out again, I'll do some performance tests on my own server using the integer field instead. The goal of that query is to tag the hit logs from spammers so they're not mistaken for real people in the logs.
I'm currently archiving the logs for january->may, but it seems reinder got a lot of traffic these days so it's rather slow (it doesn't seem to slow down the rest of the site though).
Once the archiving is done, I'll kick out the detailed data for jan->may which should free up some 150 Mb worth of data or something. I'll need to rebuild the table at that point, though, so I'll do it in small bursts so as not to inconvenience anybody.

oh, by the way ... that query is only executed when a spam is encountered. If you're seeing a lot of them it means the site is under a pretty hefty spam attack.

That's ... strange ... because I commented that line out when I noticed it slowed things down too much...

*checks*

Ah ... right ... I uploaded the updated file to the wrong place again (I keep uploading files to the root for some reason when I'm in a rush, instead of to public_html). And yeah, it should be using the indexed field of course ... serves me right for updating code without refreshing my memory.

Mea Maxima Culpa, changed it now.