Resolvendo lentidão crítica no Roundcube webmail

Resolvendo lentidão crítica no Roundcube webmail#

Seu servidor está ocioso, os sites carregam rápido, mas o Roundcube demora de 30 a 60 segundos por clique? Esse padrão geralmente indica um gargalo lógico (camadas de conexão IMAP, DNS, OPcache ou sessão de banco de dados), e não falta de hardware bruto.

Abaixo, apresento um guia passo a passo estruturado para diagnosticar e solucionar lentidões críticas de forma segura, com medidas preventivas de integridade.

1) Diagnóstico inicial: o servidor está saudável?#

Métricas comuns durante esse tipo de incidente:

load average baixo (ex: inferior a 1.0)
CPU com alta porcentagem de idle
iowait de disco próximo de 0.0%

Se o servidor está ocioso mas o Roundcube continua extremamente lento, a origem do problema é puramente lógica.

2) Investigando os logs de erros#

Antes de aplicar qualquer correção, você deve auditar as mensagens de erro nos logs do sistema:

A. Logs do Roundcube#

Localize o arquivo de erros do Roundcube para rastrear timeouts de IMAP ou falhas de gravação de sessão:

# Caminho padrão no cPanel
tail -n 100 /usr/local/cpanel/base/3rdparty/roundcube/logs/errors.log

# Caminho padrão no DirectAdmin / Debian
tail -n 100 /var/log/roundcube/errors.log

# Filtrar especificamente por falhas de sessão ou banco de dados
grep -i "session\|error" /var/log/roundcube/errors.log | tail -n 20

Se o log contiver erros como Duplicate entry ... for key 'PRIMARY' nas tabelas do Roundcube, significa que a lentidão forçou o usuário a clicar várias vezes, gerando conexões duplicadas concorrentes que travaram as tabelas do banco de dados MySQL.

B. Logs do Dovecot#

Verifique os logs de e-mail do sistema para monitorar conexões IMAP recusadas por exceder o limite de IPs:

# Filtrar logs do Dovecot por alertas de limites de IP
tail -n 100 /var/log/maillog | grep -i "dovecot"

# Buscar por mensagens de conexão recusada ou timeouts
grep -i "max_userip\|error" /var/log/maillog | tail -n 20

Se você encontrar mensagens como Empty startup greeting ou Too many connections from IP, o Dovecot está recusando conexões locais do próprio Roundcube.

3) Procedimento de correção passo a passo#

Fluxo de diagnóstico Roundcube lento#

flowchart TD A[Roundcube >30s por clique] --> B[Verificar load average / iowait] B --> C{Load normal?} C -->|Não| D[Hardware: CPU, RAM, disco] C -->|Sim| E[Verificar logs do Roundcube] E --> F{Erro DB: Duplicate entry?} F -->|Sim| G["TRUNCATE session + cache tables<br/>backup primeiro"] F -->|Não| H[Verificar logs Dovecot] H --> I{"max_userip_connections<br/>atingido?"} I -->|Sim| J[Aumentar limite para 127.0.0.1] I -->|Não| K[Testar resolução localhost] K --> L{localhost resolve para ::1?} L -->|Sim| M[Forçar 127.0.0.1 no config.inc.php] L -->|Não| N[Testar porta IMAP direta] N --> O{Porta 143 responde?} O -->|Não| P[Verificar firewalld / CSF] O -->|Sim| Q[Reiniciar PHP-FPM + Apache/Nginx]

Passo 1: Ajustar limites de conexões no Dovecot#

Por padrão, o Dovecot limita o número de conexões IMAP simultâneas vindas do mesmo IP (geralmente fixado em 10 ou 20). Como o Roundcube roda localmente no servidor, todas as conexões dos usuários webmail aparecem para o Dovecot como vindas do mesmo endereço IP (127.0.0.1). Isso faz com que o limite seja atingido quase que imediatamente em produção.

Verificação de Configuração Prévia:#

Antes de aplicar qualquer modificação, audite os limites correntes no Dovecot para conexões por IP e as configurações IMAP:

# Verificar a configuração atual de conexões IMAP e limites por IP antes de alterar
doveconf -n mail_max_userip_connections
doveconf -n protocol imap

Para corrigir isso, edite o arquivo de configuração do Dovecot (geralmente em /etc/dovecot/dovecot.conf ou /etc/dovecot/conf.d/10-master.conf). Note que a diretiva remote deve funcionar dentro do bloco do protocolo imap para surtir efeito corretivo:

# /etc/dovecot/conf.d/10-master.conf OU 20-imap.conf

protocol imap {
  # Limite padrão para conexões externas
  mail_max_userip_connections = 20
  
  # Regra de bypass específica para o localhost (Roundcube)
  remote 127.0.0.1 {
    mail_max_userip_connections = 200
  }
}

Alternativa simples suportada universalmente:

# Define globalmente, depois sobrescreve no bloco protocol
mail_max_userip_connections = 20

protocol imap {
  mail_max_userip_connections = 200
}

Após editar, valide as alterações e reinicie o serviço:

# Confirmar a leitura da nova variável de configuração
doveconf mail_max_userip_connections

# Reiniciar o serviço do Dovecot
systemctl restart dovecot

Passo 2: Forçar conexão via IP de loopback no Roundcube#

No arquivo config.inc.php do Roundcube (geralmente localizado em /var/www/html/roundcube/config/ ou /etc/roundcube/), evite usar o host localhost. Substitua-o pelo IP numérico explicitado 127.0.0.1 para contornar lentidões de resolução DNS ou caminhos IPv6 não configurados:

$config['imap_host'] = '127.0.0.1:143';
$config['smtp_host'] = '127.0.0.1:587';

Validação de Conectividade Local e DNS:#

# Validar se o DNS do localhost está resolvendo corretamente
nslookup localhost
dig localhost

# Verificar se a porta IMAP está ativa e em escuta
ss -lntp | grep 143

# Teste de conectividade IMAP/IMAPS completo e diagnóstico
echo "Test: IMAP port 143 (STARTTLS)"
echo "" | timeout 3 openssl s_client -connect 127.0.0.1:143 -starttls imap 2>&1 | grep -E "BEGIN CERTIFICATE|SSL handshake|CONNECTED"

echo "Test: IMAP port 993 (TLS direto)"
echo "" | timeout 3 openssl s_client -connect 127.0.0.1:993 2>&1 | grep -E "BEGIN CERTIFICATE|SSL handshake|CONNECTED"

echo "Test: conexão TCP pura"
timeout 2 bash -c 'echo "a1 LOGOUT" | nc 127.0.0.1 143' || echo "Falha na conexão TCP"

Passo 3: Desabilitar fontes e recursos externos#

Se o servidor estiver sob regras restritivas de firewall ou sem acesso estável à internet, requisições do Roundcube para carregar fontes externas ou scripts externos causarão timeouts pesados na renderização visual.

No config.inc.php, habilite o uso de fontes locais padrões:

$config['standard_fonts'] = true;

Passo 4: Limpeza segura do estado de sessão e cache no banco de dados#

# 1. Realizar backup das tabelas antes de qualquer limpeza
mysqldump roundcube_db session cache cache_index cache_messages > /root/roundcube-backup-$(date +%Y%m%d).sql

# 2. Limpar tabelas acumuladas de sessões corrompidas e índices órfãos
mysql roundcube_db -e "TRUNCATE TABLE session; TRUNCATE TABLE cache; TRUNCATE TABLE cache_index; TRUNCATE TABLE cache_messages;"

Nota: Se preferir uma alternativa mais conservadora e auditável em vez do TRUNCATE, utilize comandos DELETE:

mysql roundcube_db -e "DELETE FROM session; DELETE FROM cache; DELETE FROM cache_index; DELETE FROM cache_messages;"

Passo 5: Reiniciar processos PHP e web server correspondentes#

Após as alterações de arquivos de configuração e banco, recarregue os processos de execução do PHP para limpar o cache OPcache e liberar sockets presos:

Stacks sob LiteSpeed (LSPHP)#

# Reiniciar processos de forma graciosa primeiro (SIGTERM), permitindo liberar session locks e conexões MySQL
killall -u webapps -15 lsphp 2>/dev/null
sleep 2
# Fallback forçado (SIGKILL) apenas se houver processos órfãos travados
killall -u webapps -9 lsphp 2>/dev/null

# Reiniciar o painel LiteSpeed
/usr/local/lsws/bin/lswsctrl restart

Stacks sob Apache e PHP-FPM#

# Reiniciar o pool do PHP-FPM
sudo systemctl restart php-fpm

# Reiniciar o servidor Apache
sudo systemctl restart apache2

Stacks sob Nginx e PHP-FPM#

# Reiniciar o pool do PHP-FPM
sudo systemctl restart php-fpm

# Reiniciar o servidor Nginx
sudo systemctl restart nginx

4) Verificação pós-fix e validação de performance#

Após aplicar os ajustes, certifique-se de que a latência foi mitigada com sucesso:

Testar login via interface web: Acesse a url de webmail do seu servidor (ex: https://domain.com:2096) e efetue login.
Medir tempo total de resposta de requisição:

Use a flag -k no curl para contornar o erro de certificado autoassinado (CN mismatch) ou associado a loopback, permitindo a medição precisa da latência do cPanel webmail:

   time curl -sk -o /dev/null -w "%{time_total}" https://127.0.0.1:2096

Auditar conexões ativas no Dovecot:

   doveadm who

Verificar métricas de performance do Dovecot (conexões, latência, comandos):

   # Exibe estatísticas acumuladas: conexões ativas, tempo médio de resposta,
   # contagem de comandos IMAP e operações de disco por sessão
   doveadm stats dump

5) Prevenção de recorrência e manutenção avançada#

Para evitar que o banco de dados do Roundcube volte a sofrer com contenção de escrita de cache e sessões órfãs no futuro:

A. Limpeza automática de sessões via cron#

Adicione um script cron diário para expurgar sessões obsoletas com mais de 7 dias de inatividade:

# Adicionar ao crontab do root (crontab -e)
0 3 * * * mysql roundcube_db -e "DELETE FROM session WHERE changed < NOW() - INTERVAL 7 DAY;" 2>&1 | logger -t roundcube-cron

B. Rotação de logs do Roundcube#

Evite que arquivos de erros cresçam infinitamente no disco configurando um arquivo de logrotate em /etc/logrotate.d/roundcube:

/var/log/roundcube/errors.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

C. Auditoria das configurações do PHP e opcache#

Garantir limites adequados de memória e processamento para os scripts do Webmail:

# Verificar limites de memória e execução ativos do PHP CLI
php -i | grep -E "memory_limit|max_execution_time"

# Confirmar se o OPcache está ativado no runtime
php -v | grep -i "opcache"

D. Auditoria de quota de caixas de e-mail via doveadm#

Problemas de cota (quota) também podem causar lentidão severa. Audite as caixas de e-mail com desregulação usando:

# Verificar status de quota e contagem de mensagens de uma caixa
doveadm mailbox status -u [email protected] "messages" INBOX

E. Otimização de performance no cache e anexos do Roundcube#

Em instâncias de alto tráfego ou contas com muitos anexos, o Roundcube pode sofrer contenção de escrita de banco se configurado com os plugins padrão database_attachments e db_cache.

Anexos (database_attachments plugin): O plugin armazena temporariamente anexos na tabela attachments do MySQL. Se houver concorrência de upload de grandes arquivos, o banco trava. Considere drivers de arquivo temporário locais ou externos se o volume for alto.
Cache (db_cache plugin): O cache de mensagens em tabelas relacionais do banco deve ser migrado para Redis ou Memcached se disponível, aliviando escritas concorrentes no banco.

Checklist de troubleshooting: lentidão no Roundcube#

Utilize este checklist para auditoria em tempo real em servidores de e-mail de produção:

1. Diagnóstico e triagem#

[ ] O load average do servidor está normal? uptime
[ ] Existe lentidão na CPU ou iowait de disco? top
[ ] Verificou erros de banco de dados nos logs do Roundcube?
[ ] Verificou conexões recusadas no /var/log/maillog?

2. Configurações do Dovecot e conectividade#

[ ] O limite mail_max_userip_connections foi estendido para o localhost (200+)?
[ ] O serviço do Dovecot foi reiniciado? systemctl restart dovecot
[ ] O comando doveadm who mostra as sessões atuais?
[ ] O arquivo config.inc.php do Roundcube usa 127.0.0.1 em vez de localhost?
[ ] Conexão local via porta 143/993 responde imediatamente?

3. Banco de dados e cache#

[ ] Foi realizado o backup da base de dados com mysqldump?
[ ] As tabelas session e cache foram higienizadas com sucesso?
[ ] A limpeza automática de sessões antigas está configurada no cron?

4. Servidor web e PHP#

[ ] Os processos do PHP-FPM ou LSPHP foram reiniciados?
[ ] O OPcache está ativo para otimizar os scripts PHP?

Considerações práticas#

Lentidão crítica no Roundcube geralmente é o resultado de gargalos de rede (IPv6 / DNS lento) associados a limites restritivos de conexão local no Dovecot e travamentos de tabelas MySQL. Ao forçar o loopback IPv4 (127.0.0.1), aumentar a tolerância de conexões locais e restaurar o estado limpo das tabelas do banco com backup prévio de segurança, o webmail retoma o tempo de resposta instantâneo.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.