Servidor do Moodle caindo e alunos sem conseguir entregar as tarefas

Caso real de produção, contado sem identificar o cliente. Uma plataforma Moodle chegou até nós depois de uma migração mal gerida por quem cuidava dela antes. O sintoma era do tipo que tira o sono de qualquer coordenador: o servidor vivia caindo e, pior, os alunos não conseguiam entregar as tarefas — quase sempre no horário do prazo, o pior momento possível. A cada fechamento, uma enxurrada de mensagens de "não consigo enviar".

Quando isso acontece, a conclusão apressada é "o Moodle é ruim" ou "precisamos trocar de plataforma". Quase nunca é o caso. O problema não estava no Moodle — estava no que a migração mal feita deixou para trás.

Por que o erro aparece logo na entrega da tarefa

A entrega de uma tarefa é uma das operações mais pesadas para o aluno: ele faz upload de um arquivo, muitas vezes grande, e o servidor precisa recebê-lo e gravá-lo. Se a configuração está apertada, é exatamente aí que quebra. Some a isso o efeito manada — todo mundo entrega perto do prazo — e você tem o pico de carga caindo em cima da operação mais frágil. Não é azar; é configuração e dimensionamento.

As causas de verdade por trás do sintoma

Numa herança de migração mal feita, o estrago costuma estar espalhado em vários pontos ao mesmo tempo:

• Limites de upload do PHP baixos. upload_max_filesize, post_max_size e max_input_time menores do que o arquivo (ou o tempo) que a tarefa exige. O aluno tenta enviar e o servidor corta no meio — o clássico "não consigo entregar".
• Servidor subdimensionado para os picos. Recursos que aguentam o uso normal, mas não o momento em que centenas de pessoas entregam ao mesmo tempo.
• Cron parado ou acumulado. Migração que esqueceu de religar o cron: tarefas em segundo plano, notificações e filas empilham até engasgar tudo.
• Cache desligado. Sem cache, cada acesso pesa muito mais — e no pico o servidor não dá conta.
• Banco e logs sem retenção. Tabelas de log crescendo sem limite deixam cada operação mais lenta, até o ponto de queda.
• Nenhum teste de carga pós-migração. A plataforma "subiu e funcionou" num dia calmo — e só quebrou quando veio o primeiro prazo real.

Como estabilizamos

O caminho não é chutar: é medir e corrigir na causa. Ajustamos os limites de upload do PHP para o tamanho real das tarefas, dimensionamos os recursos para o pico (e não para a média), religamos o cron para rodar de minuto em minuto, ativamos e configuramos o cache, definimos retenção de logs e limpamos o que já tinha inchado. Por fim — a parte que a gestão anterior pulou — validamos com o cenário de pico, simulando o comportamento de fechamento de prazo antes do próximo prazo real.

O resultado

O servidor parou de cair e, o que mais importava, os alunos voltaram a entregar as tarefas normalmente — inclusive na correria do prazo. A plataforma era a mesma; o que mudou foi a configuração e o dimensionamento que a migração tinha deixado quebrados.

A moral do caso é dura, mas útil: uma migração não termina quando o site abre. Termina quando ele aguenta o pior dia — o do prazo. Fornecedor que "sobe e some" deixa exatamente esse tipo de bomba-relógio para trás. Sobre isso, veja o custo do fornecedor que some; e sobre lentidão em geral, por que o Moodle fica lento.