Still keeping an eye on the Stat Server's memory usage. Also noticed it was running at "nice 10" which has been fixed thanks to "renice 1 -p 60227".
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
33914 rei 1 54 10 9340K 2892K select 0 5:42 0.00% screen
60227 rei 1 45 1 10920K 7500K accept 3 5:30 0.00% ss
Memory usage didn't immediately go up after freeing 4500 records.
We're using GLib C's malloc() and free() memory management features. Every call to free places the reallocated block on a free list. So if I deleted everything, there's always a chance sbrk() could be called to reduce the heap size. But given the nature of this program... that seems unlikely. The newest records are at the end, and the ones freed with be scattered all over the place, most densely packed at the beginning. Of course, after a free, the memory will be reused before the next sbrk() is made ... anyways, so long as we never go near 100M, I think I'll feel confident there are no memory leaks. But if it goes above 30M or 50M without much change in records, I'll have to consider using a MemLeak detector.
Also this time Bing was doing a DoS. lol What's with them requesting 30 pages in 2 seconds? Could be a spoofed User Agent. Meh... no harm done.
Add a Character 
A-Z Characters
Top 5 by Year
Latest
Tags
Lists
A-Z Series
Calendar
Who
News