Well, this is most excellent news. We've isolated the slowdown to a single php page on the stats site, and a single change made to the code on that php page.
We had recently made a modification to the /rc5-64/psearch.php queries that pulled the search data from a different table than it normally pulls from. For some reason, this is running much, much slower than it should and is causing the incredible slowdown while stats are up and available.
When we remove access to this one page (rc5-64/psearch) stats seems to run just fine and dandy. So, at this point, the worst-case scenario we're looking at is not being able to do a participant search while the daily processing is running. At least until we can figure out why the query is running so slowly.
I've already rebuilt the relevant indexes and that hasn't helped any, so there's still more debugging we need to do. The good news is that since we know what has to happen to repair the performance, I can go ahead and start catching up the rc5-64 data to bring it current.
More details as the situation progresses.