Couple of things off the top of my head:
Suda is currently running on 32-bit Linux. At least under the present
configuration, MySQL will crash unless we keep it tuned to memory usage
under 2GB. (We had to reduce the InnoDB page space by about 500MB from
the config file we used on Gunther, which was running 64-bit.) The
remaining 2GB are in use as disk cache, but it'd be nice to let MySQL
handle its needs more directly. E23 thinks we can upgrade just the
kernel and libc and maybe make things work... I dunno. Anyway we'll
probably just keep moving on what we've got until we've got the other
Opteron in florida to take over from it.
The load average tends to be 4-ish; a bit higher than I'd like. Search
is still off, but updates to the search tables on edit are active. When
I briefly tried enabling search it was _very_ sluggish. We'd probably
want to expand the key buffer size from its current 128MB, as the
english search index alone is over 300 megs. But, see our current
memory problems above.
Disk space: it's a little tighter than I'd like but not fatal.
(Currently 12ish gigs free out of 68ish on main partition.) I'm
currently running the batch compression on old revisions which should
save 10-15GB (est), but this space can't be reclaimed without dumping
and restoring the databases. That would require several hours'
downtime, or waiting until we've got a replicated slave to take over.
It may or may not be worth the trouble of reclaiming the space anyway,
as it'll just get filled up again eventually. ;) However the innodb
space currently is split over three files because they were copied from
a system that had to split over partitions. I don't know if that has
any performance penalty for files sitting on one (virtual) disk, or if
fragmentation is an issue.
-- brion vibber (brion @
pobox.com)