Moodle Lento: As Causas Reais e Como Diagnosticar

Moodle lento raramente é culpa de servidor pequeno. Na maioria dos chamados que atendo, a lentidão vem de três coisas que não custam nada para corrigir: cache desligado, cron atrasado e banco sem tuning. Este guia mostra como diagnosticar em 30 minutos, quais números pedir antes de assinar um contrato maior e como reconhecer os casos em que trocar de servidor é, de fato, a decisão certa.

TL;DR

• Moodle lento é sintoma, não diagnóstico. Meça TTFB, tempo de geração da página e número de queries por página antes de qualquer coisa.
• As causas mais comuns são de configuração: theme designer mode ligado, MUC e sessões em disco, OPcache ausente, cron rodando de hora em hora e tabela de log inchada.
• O relatório Visão geral de desempenho (Administração do site → Relatórios) aponta três desses problemas em 10 segundos.
• Trocar de servidor só resolve quando o gargalo é saturação real de CPU, RAM ou I/O — e isso se prova com métrica, não com sensação.
• Moodle 5.1 (06/10/2025) exige PHP 8.2+ e mudou o document root para /public; Moodle 5.2 saiu em 20/04/2026 e a próxima LTS, a 5.3, está prevista para 05/10/2026.

Trabalho com Moodle desde 2008 e já operei ambientes com dezenas de milhares de alunos em picos de matrícula e semana de provas. Quase toda vez que um cliente chega dizendo que quer um servidor maior, o problema está na camada de software. E quando o servidor realmente é o gargalo, dá para provar em minutos — com número, não com achismo.

Moodle lento: o que é lentidão de verdade e como medir

A primeira armadilha é semântica. A expressão Moodle lento é usada para descrever pelo menos cinco problemas diferentes, e cada um tem uma causa distinta:

• Página demora a começar a carregar — o servidor está pensando demais. É TTFB (Time To First Byte), e aponta para PHP, banco ou cache.
• Página carrega, mas fica meio quebrada e lenta para responder ao clique — é front-end: JavaScript e CSS sendo servidos sem cache, sem compressão ou sem CDN.
• Só a página de um curso específico é lenta — é conteúdo: curso com centenas de atividades, filtro pesado, plugin mal escrito.
• Fica lento só das 19h às 22h — é concorrência. O servidor aguenta o dia, não aguenta o pico.
• Fica lento na semana de provas — é o questionário. O módulo quiz é o mais pesado do Moodle para o banco de dados.

Os três números que você precisa antes de abrir chamado

Antes de conversar com qualquer fornecedor, colete:

1. TTFB medido de fora, com curl -w "%{time_starttransfer}\n" -o /dev/null -s https://seu-moodle/. Rode dez vezes, em horário de pico e fora dele.
2. Tempo de geração da página e número de queries, que o próprio Moodle informa no rodapé quando você liga o performance info.
3. Uso de CPU, RAM e I/O do servidor no mesmo intervalo, com top, vmstat 1 e iostat -x 1.

Se o TTFB é de 3 segundos e a CPU está em 20%, o servidor não é o problema. Guarde essa frase — ela economiza contratos inteiros.

As causas de aplicação que derrubam o Moodle sem culpa do hardware

Estas são as que encontro com mais frequência em auditoria. Todo Moodle lento que passou pela minha mesa tinha pelo menos duas delas — e todas se resolvem sem trocar uma linha de hardware.

Theme designer mode ligado

É a causa número um de Moodle lento na minha lista. Com o theme designer mode ativo, o Moodle recompila CSS e JavaScript a cada requisição de cada usuário. A própria documentação do Moodle avisa que isso derruba o desempenho de forma dramática. Alguém liga para ajustar uma cor no tema, esquece de desligar e o site fica arrastado por meses. Verifique em Administração do site → Aparência → Temas → Configurações de tema.

MUC e sessões em disco

O Moodle usa o MUC (Moodle Universal Cache), um sistema de cache em camadas para definições de curso, contextos, strings de idioma e permissões. Por padrão, ele vive no sistema de arquivos. Em site pequeno funciona; a partir de algumas centenas de usuários simultâneos, cada leitura vira I/O.

O mesmo vale para as sessões. A documentação de session handling do Moodle recomenda o driver Redis, e diz explicitamente que sessões em banco de dados têm desempenho baixo e não são recomendadas para sites grandes. A configuração vai no config.php:

$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_prefix = 'meusite_us_';
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_lock_expire = 7200;

Um detalhe que quase ninguém sabe: o Moodle bloqueia a sessão durante a requisição. Se uma página pesada segura o lock por 20 segundos, as outras abas daquele mesmo aluno ficam esperando. O usuário jura que o Moodle lento é do servidor; na verdade é ele competindo consigo mesmo.

OPcache desligado ou subdimensionado

A documentação oficial de recomendações de desempenho é direta: garanta que o acelerador embutido do PHP — o OPcache — esteja habilitado. Sem ele, o PHP reinterpreta milhares de arquivos a cada clique. Site com OPcache desligado é Moodle lento garantido, mesmo em máquina folgada: é o ajuste com melhor relação entre esforço e ganho que existe no Moodle. Confira com php -i | grep opcache.enable e olhe a taxa de acerto: se opcache_get_status() mostra misses subindo o tempo todo, a memória do OPcache está pequena para o tamanho do seu código mais os plugins.

Cron atrasado ou rodando por HTTP

A documentação recomenda executar o cron a cada minuto, e sempre por CLI (php admin/cli/cron.php), nunca por chamada HTTP — em instalações grandes, o cron por HTTP consome memória demais. Cron atrasado não é o tipo de Moodle lento que aparece no TTFB; ele acumula fila. Notificações, índice de busca, limpeza da lixeira e processamento de notas se empilham e explodem tudo de uma vez. Em Administração do site → Servidor → Tarefas agendadas você vê a última execução de cada tarefa. Se há tarefas que deveriam rodar de hora em hora e rodaram ontem, achou um problema.

Tabela de log inchada e estatísticas ligadas

O mdl_logstore_standard_log cresce sem parar. Em EAD ativo, passa de dezenas de milhões de linhas em um ano. Relatórios e o bloco de atividades recentes passam a varrer essa montanha. Ajuste o tempo de vida dos logs em Administração do site → Servidor → Limpeza, e desligue as estatísticas se você não as usa — o relatório de desempenho do próprio Moodle recomenda exatamente isso.

As causas de infraestrutura: quando o gargalo é real

Banco de dados sem tuning

Um MariaDB com configuração padrão trabalha com um buffer pool minúsculo. A recomendação da documentação do Moodle para máquina dedicada a banco é innodb_buffer_pool_size em torno de 80% da RAM, com innodb_buffer_pool_instances acompanhando o número de núcleos de CPU. Se o seu banco tem 40 GB e o buffer pool tem 128 MB, cada consulta vai ao disco. Buffer pool subdimensionado é a causa mais comum de Moodle lento no horário de pico, e não existe servidor grande o bastante para compensar isso.

Vale lembrar os mínimos de versão do Moodle 5.1: PostgreSQL 15, MySQL 8.4 ou MariaDB 10.11. Rodar abaixo disso não é só risco de suporte — é abrir mão de otimizações do próprio banco.

PHP-FPM mal dimensionado

Workers de menos criam fila: as requisições esperam em listen.backlog e o aluno vê a página congelada. Workers demais estouram a RAM e o sistema começa a usar swap — aí sim o Moodle lento vira Moodle travado. A conta é simples: pegue o consumo médio real de um worker (normalmente 60–120 MB em Moodle com plugins) e divida a RAM disponível para PHP por esse valor.

Disco, rede e assets

A documentação de instalação sugere 200 MB para o código mais espaço para conteúdo, com 5 GB como mínimo realista, e 8 GB de RAM ou mais para servidores de produção grandes. Mas o número que mais dói é o IOPS. Moodle com moodledata em disco de rede lento, ou em NFS mal configurado, entrega TTFB alto mesmo com CPU ociosa. Já vi ganho de 60% só movendo o localcachedir para disco local rápido.

Roteiro de diagnóstico de Moodle lento em 30 minutos

Faça nesta ordem. Cada passo elimina uma hipótese.

Passo 1 — abra o relatório de desempenho

Administração do site → Relatórios → Visão geral de desempenho. Ele checa, entre outros itens, se o theme designer mode está ligado, se o cache de JavaScript (cachejs) está ativo e se as estatísticas estão sendo gravadas. Três cliques, três causas eliminadas.

Passo 2 — ligue o performance info

Em Administração do site → Desenvolvimento → Depuração, ative Performance info. O rodapé passa a mostrar tempo de geração, memória e cache hit/miss. Para contar queries, adicione ao config.php:

define('MDL_PERF', true);
define('MDL_PERFDB', true);
define('MDL_PERFTOFOOT', true);

Página institucional com mais de 200 queries é sinal de plugin ou bloco mal comportado. Página de curso com 1.500 queries é bug, não é falta de servidor.

Passo 3 — registre as queries lentas

Ainda no config.php, o Moodle permite registrar consultas acima de um limiar na tabela mdl_log_queries, via dboptions com logslow. Rode por um dia inteiro e olhe as dez piores. Costuma ser sempre a mesma consulta, do mesmo plugin.

Passo 4 — correlacione com o horário

Cruze o TTFB com o gráfico de CPU e de conexões do banco. Moodle lento apenas no pico é problema de dimensionamento; Moodle lento o tempo todo é problema de configuração. É a distinção mais importante de todo o diagnóstico.

Tabela de sintoma, causa provável e onde olhar

Sintoma	Causa provável	Onde verificar	Correção típica
Lento o dia inteiro, CPU baixa	Theme designer mode / OPcache off	Visão geral de desempenho; php -i	Desligar designer mode; ligar OPcache
Lento só no pico da noite	Workers PHP-FPM ou banco saturado	top, conexões do MariaDB	Redimensionar pool; tuning do InnoDB
Lento após ativar um plugin	Queries em laço	Performance info (nº de queries)	Substituir ou corrigir o plugin
Notificações e notas atrasadas	Cron atrasado ou por HTTP	Tarefas agendadas	Cron por CLI a cada minuto
Relatórios travam o site inteiro	mdl_logstore_standard_log gigante	Tamanho da tabela	Reduzir log lifetime; réplica de leitura
Login lento, abas travando	Lock de sessão em disco	config.php	Sessões em Redis

O checklist de tuning que resolve a maioria dos casos de Moodle lento

Se eu tivesse uma hora e acesso root, faria exatamente isto, nesta ordem:

1. Desligar theme designer mode e ligar cachejs.
2. Habilitar e dimensionar o OPcache; revisar memory_limit no php.ini.
3. Mover sessões para Redis e apontar os stores do MUC para Redis também.
4. Ajustar innodb_buffer_pool_size e innodb_buffer_pool_instances no MariaDB.
5. Colocar o cron por CLI a cada minuto, em usuário e worker próprios.
6. Reduzir o log lifetime e desligar estatísticas não usadas.
7. Colocar localcachedir em disco local rápido.
8. Publicar assets estáticos atrás de CDN com compressão.

Na média dos ambientes que assumi, esse checklist derrubou o TTFB de 3–4 segundos para menos de 1 segundo — sem trocar uma máquina. É o mesmo trabalho que fazemos no onboarding da nossa hospedagem gerenciada de Moodle, antes de discutir qualquer aumento de plano.

Quando trocar de servidor é a resposta certa, e quando não é

Trocar faz sentido quando, com o checklist acima já aplicado, você observa:

• CPU acima de 80% sustentados no pico, com fila de execução (load average) acima do número de núcleos;
• RAM saturada com swap ativo — swap em servidor de banco é sentença de lentidão;
• I/O wait de dois dígitos no iostat;
• Banco e web disputando a mesma máquina, com o buffer pool já no teto do que a RAM permite;
• Crescimento previsto que você consegue projetar: dobrar alunos no semestre seguinte, por exemplo.

Não troque quando: o problema aparece só em uma página, só depois de instalar um plugin, só na semana de provas (aí é o quiz e o cron), ou quando ninguém mediu nada. Servidor maior com cache desligado continua sendo Moodle lento — só que mais caro. Já peguei cliente que triplicou o custo mensal de infraestrutura e ganhou 8% de TTFB, porque o gargalo era mdl_log com 90 milhões de linhas.

Vale a comparação com os números que a própria comunidade usa como referência de escala: a documentação de desenvolvimento cita instalações chegando a 1 milhão de usuários, 50 mil cursos e 5 mil usuários por curso. Se o seu Moodle tem 3 mil alunos e está lento, o problema quase certamente não é capacidade.

Armadilhas e custos que ninguém conta na hora da migração

Versão do PHP. O Moodle 5.1 exige PHP 8.2 no mínimo, e aceita 8.3 e 8.4, apenas em 64 bits, com a extensão sodium e max_input_vars de pelo menos 5000. Migrar para um servidor com PHP antigo é migrar para um beco sem saída.

A mudança do /public. A partir do Moodle 5.1 existe um diretório /public, e o document root do servidor web precisa apontar para ele — não mais para a raiz do Moodle. Quem migra copiando o vhost antigo quebra o site ou expõe arquivos que não deveriam ficar acessíveis. Plugins instalados antes do upgrade continuam no lugar antigo e precisam ser movidos manualmente.

Ciclo de versões. O Moodle 4.5 LTS teve o suporte geral encerrado em 06/10/2025 e mantém apenas suporte de segurança até 04/10/2027. O 5.2 chegou em 20/04/2026 e a próxima LTS, a 5.3, está prevista para 05/10/2026. Planeje a migração de servidor junto com a de versão — fazer as duas separadas custa duas janelas e dois períodos de risco. Escrevi sobre esse cálculo no post de versão, LTS e upgrade do AVA da UFBA, e o caso da atualização do PVANet da UFV para o Moodle 4.5 mostra o tamanho real do esforço em uma instituição pública.

Custo de conviver com Moodle lento. Cada semestre adiando o diagnóstico é evasão, chamado no suporte acadêmico e professor migrando conteúdo para fora do AVA. Esse custo não entra na planilha de infraestrutura, mas é o maior de todos.

Custo escondido do downtime. Uma janela mal planejada em semana de provas custa mais que um ano de diferença de plano. O padrão de acesso de instituição pública, com pico concentrado no início de semestre, está bem ilustrado no que analisei sobre o pico de acesso do Moodle da UTFPR em 2026/2.

Como a Agathas Web resolve isso

Nossa hospedagem gerenciada de Moodle começa exatamente pelo diagnóstico descrito acima — e o diagnóstico inicial é gratuito, mesmo que você decida ficar onde está.

O que está incluso:

• Stack afinada para Moodle, não hospedagem genérica: PHP-FPM com pool dedicado por instância e OPcache ajustado, Redis para sessões e MUC, MariaDB 10.11+ com binlog, Nginx e cron isolado em worker próprio.
• Monitoramento 24/7 com Grafana, Sentry e verificação externa de uptime, com alerta na equipe técnica antes de o aluno reclamar.
• Backup diário com binlog incremental a cada 15 minutos, storage offsite criptografado e restore testado todo mês.
• Migração assistida em até 5 dias úteis, com paridade de usuários, cursos, notas, badges e fóruns, homologação em staging, cut-over em janela noturna ou de fim de semana e ambiente antigo preservado por 30 dias para rollback.
• SLA contratual de 99,9% de uptime, resposta em até 15 minutos para incidentes críticos e suporte sênior em português, por WhatsApp, sem nível 1 lendo roteiro.
• Relatório mensal com uso de recursos, eventos críticos, backups testados e melhorias sugeridas.

Como funciona na prática: você nos dá acesso de leitura ao ambiente atual, rodamos o diagnóstico e devolvemos um documento apontando o gargalo, o ganho esperado de cada correção e o dimensionamento que faz sentido. Se o seu servidor atual dá conta depois do tuning, dizemos isso. Se não dá, a migração já vem orçada.

Como se contrata: pelo formulário da página de hospedagem gerenciada de Moodle ou pelo WhatsApp da equipe técnica. Contratos mensais, sem fidelidade longa, com cancelamento em 30 dias e devolução dos dados em formato padrão.

Conclusão: diagnostique, depois decida

Moodle lento é sintoma, não diagnóstico. Meça TTFB, conte queries, olhe as tarefas agendadas e rode o relatório de visão geral de desempenho antes de qualquer decisão de infraestrutura. Na maioria dos casos, o ganho está em configuração — e é grande. Quando o gargalo for mesmo capacidade, você terá número para justificar a troca, e não uma sensação.

Se quiser começar pelo diagnóstico, é o primeiro passo da nossa hospedagem gerenciada de Moodle: apontamos os gargalos do seu ambiente atual e a proposta de correção antes de qualquer contrato.