Estávamos tendo problemas com o servidor com muito mais freqüência do que o aceitável. A causa era, basicamente, uma rede zumbi inteira enviando spam para alguns de nossos domínios, fazendo com que o SpamAssassin ocupasse uma fatia considerável de processamento, deixando pouco ou quase nenhum processamento disponível para o Apache e o MySQL.
Foi difícil de resolver este problema, que começou por volta das 14h, devido à quantidade de IPs diferentes que estavam bombardeando, literalmente, nosso servidor de e-mail. Para ser bem honesto, esse problema parou de incomodar quando o ataque parou, por volta das 15h 45min. Alguns poucos minutos de refresco para o servidor e ele voltou a arriar. A carga era tão grande que nem por SSH eu conseguia conectar para identificar o problema que estava ocorrendo.
Por fim, consegui entrar no servidor e derrubar o MySQL, o que fez com que os sites que não usam bancos de dados ficassem rápidos como uma bala (o que reforça a necessidade de configurarmos logo o segundo servidor, ação para a qual carecemos ainda de quatro novas revendas).
Uma vez derrubado o MySQL, era necessário descobrir qual era a conta que estava consumindo CPU em excesso, e por quê. Por isto suspendi todas as contas, e fui repondo uma por uma, e observando o comportamento do servidor. Algumas contas, de clientes que já foram ou estão sendo contactados pessoalmente, apresentaram um consumo um pouquinho mais alto, mas nada que comprometesse o servidor. Como Murphy é implacável, na última conta a ser restaurada o problema se manifestou. Foi só colocar o site de volta para o servidor parar a ponto de ser necessário reiniciar a máquina para poder obter o controle novamente a fim de suspender o domínio para fins de diagnóstico.
Conversando com o dono da conta — e essa informação só diz respeito a ele e a mim, lamento mas não citarei nomes aqui — pedi autorização para verificar os seus plugins e identificamos o maldito do WP-Shortstats (sem link, porque você não vai querer baixar mesmo) derrubando o servidor.
Em um blog de baixa visitação o WP-SS (para os íntimos) não chega a ser tão crítico. Contudo, quando o site está sendo indexado pelo Googlebot a carga extra de processamento é muito, muito mais alta. Como o site em questão não era um site pequeno, a passagem dos robôs de indexação nas páginas rastreadas pelo WP-SS implicava uma utilização medonha de recursos em um período muito curto, sobrecarregando o sistema por inteiro.
Destarte, caros VIPs, fica aqui a terminante proibição de utilizar qualquer plugin de estatísticas para WordPress, incluindo o Wp-Stats. Recomendo que utilizem serviços externos e especializados, como o Clicky, que permite inclusive visualizar os visitantes em tempo real.
A razão pela qual os serviços externos são o ideal é simples: no caso de plugins de estatística, toda e qualquer requisição feita ao WordPress gera um absurdo número de consultas no MySQL (em linguagem de banco de dados, uma “consulta” é qualquer operação, inclusive inclusão e exclusão de registros); quando alguma página fica bem rankeada para termos da moda, ou quando o Googlebot (ou o Slurp, ou qualquer outro bot de indexação) passa pelo site para registrar as modificações nos mecanismos de busca, esse volume absurdo de consultas do WP-SS é multiplicado pelo volume de páginas requisitadas pelo bot, num período tão curto quanto o Googlebot pode ser rápido e impaciente. Já no caso de serviços externos, o trecho de código que é interpretado, e portanto o que aciona o serviço de estatística é externo, não ocasionando o uso de CPU do servidor.
Quem tiver dúvidas pode por favor me procurar, e terei prazer em conversar.
E assim que este texto for publicado (já foi, pois você o está lendo) farei um script que me alertará sempre que um script de estatísticas for instalado no WordPress, e eu, na qualidade de administrador do sistema e responsável pela estabilidade dele, farei a remoção dos scripts, para evitar este tipo de problema no futuro.

Eita pluginzinho danado…
Super Jânio, ativar!
Que a força esteja com você!