So here we see Wallet 15r1c move 590 BTC to a couple other wallets, incurring 1.014 BTC Tx fee, which then manage to get the coin to Wallet 1KNCQ who gives it back to 15r1c all in the same second, which means they all get rolled up in the same block, incurring a total of 1.39454 BTC worth of Tx Fees. And so on and so forth.... This is but an example of why some blocks have HUGE Tx Fees.
You go around looking at some of these wallets, and you can see some pretty amazing amounts of coin doing neat tricks!
Where are you finding 1.014 TX fees? That looks like a normal wallet sending coins. When you send coins, the remainder goes to a change address. What you were doing was basically just following the change addresses. The fees on each TX were 0.0005, which is the standard TX fee for coins without high priority (low confirmation count).
I've detected problems in bitcoind 0.8.1 where high number of transactions in memory pool caused 100% CPU load on the pool server. Because of this, submitting of new blocks were delayed for tens of seconds and caused high invalid rate.
Sipa (the bitcoin developer) implemented fix for this problem (
https://github.com/bitcoin/bitcoin/pull/2677) which I just tested and implemented to the pool server. I'm watching the pool closely, but the CPU load dropped from 100% back to 2-3%, so everything looks fine so far...
Thank you for posting a link to that patch slush. I had been seeing a lot of similar issues lately (though I wasn't getting the orphan rates, since my pool servers stop accepting/submitting shares when they already see a new block, even if no work has been provided yet). Was using some workarounds the p2pool guys have used, but it still required a lot of monitoring and bitcoind restarts.