Erros de memória e de tempo de execução no PrestaShop: memory_limit e companhia

Lança uma importação de produtos e a meio ela para com um ecrã em branco. Uma tarefa agendada que sincroniza o stock está há semanas sem terminar. A exportação de encomendas funciona com um mês, mas não com um ano. No registo de erros aparecem mensagens como Allowed memory size of ... bytes exhausted ou Maximum execution time of ... seconds exceeded.

São os dois limites mais habituais do PHP, e há mais do que parece. Vamos ver quais são, onde se configuram e quando faz sentido aumentá-los.

Os limites envolvidos

memory_limit

A memória máxima que um processo PHP pode usar. Se o pedido a ultrapassar, o PHP interrompe-o com um erro fatal: Allowed memory size exhausted. Na loja vê-se como um ecrã em branco ou um erro 500.

max_execution_time

O tempo máximo, em segundos, que um script pode estar em execução. Ao ultrapassá-lo, o PHP para-o: Maximum execution time exceeded. Atenção: em Linux este contador não inclui o tempo que o script passa à espera da base de dados ou de uma API externa, apenas o tempo de execução próprio.

Os que estão fora do PHP

Mesmo que o PHP não o tenha interrompido, o pedido pode morrer antes por outro lado:

• O gestor de processos do PHP (PHP-FPM) tem o seu próprio tempo máximo por pedido.
• O servidor web ou o proxy (Apache, Nginx, um balanceador ou uma CDN) fecham a ligação se não receberem resposta num certo tempo. O cliente vê um erro 502 ou 504, enquanto o script talvez continue a executar-se por trás.
• A base de dados pode cortar ligações inativas ou consultas demasiado longas.
• max_input_vars, que não é de memória nem de tempo mas dá sintomas parecidos: limita quantos campos um formulário aceita. Uma página de produto com muitas combinações ou um ecrã de traduções pode guardar só uma parte dos dados sem mostrar nenhum erro visível.

Onde se configuram

Depende do alojamento:

• No painel do alojamento, na secção de configuração do PHP: é o mais habitual.
• Num ficheiro php.ini ou .user.ini na raiz do site, se o alojamento o permitir.
• Na configuração do servidor, se tiver um VPS ou um servidor dedicado.

Para saber que valores tem de facto a loja, não confie no que diz o painel: confirme-o na informação do servidor do back-office (Parâmetros avançados → Informação) ou com uma página temporária que mostre a configuração do PHP, e apague-a depois.

Onde aparecem no PrestaShop

• Importações CSV grandes, sobretudo com imagens descarregadas de um URL durante a importação.
• Regeneração de miniaturas em catálogos com muitas fotos ou fotos muito grandes.
• Tarefas agendadas de módulos que sincronizam com um ERP, um fornecedor ou um marketplace.
• Exportações de encomendas, clientes ou produtos de períodos longos.
• Geração de PDFs com muitas faturas de uma vez.
• Esvaziar a cache ou recompilar o contentor do Symfony no PrestaShop 8 e 9, o que precisa de bastante memória de uma só vez.
• Páginas concretas: uma categoria com milhares de produtos sem paginação, um produto com centenas de combinações, uma ficha de encomenda com muitas linhas.

Quando aumentar o limite e quando não

Aumentar memory_limit ou max_execution_time é razoável quando o processo é legitimamente grande e pontual: uma importação inicial, uma migração, uma regeneração completa. O PrestaShop exige por si só um mínimo de memória generoso, e muitos alojamentos vêm com valores abaixo do que a loja precisa.

Mas se de cada vez precisar de mais, o problema é outro:

• Um processo que carrega tudo em memória (todos os produtos, todas as encomendas) em vez de trabalhar por lotes. Com o catálogo de hoje cabe; com o do próximo ano, não.
• Um ciclo que não termina ou que processa o mesmo uma e outra vez, por um erro do módulo.
• Consultas sem índice sobre tabelas que cresceram, que demoram cada vez mais.
• Chamadas lentas a APIs externas dentro do mesmo processo, uma por produto.

Se um limite enorme «resolve» uma página normal da loja, como uma categoria ou uma página de produto, não está resolvido: essa página consome recursos que não devia, e com tráfego vai deitar o servidor abaixo.

Como diagnosticar

1. Leia a mensagem completa no registo de erros do PHP: indica o ficheiro e a linha onde a memória ou o tempo se esgotou. Às vezes é a linha de um módulo concreto; outras, uma função do núcleo chamada a partir de um módulo.
2. Distinga web e terminal: a falha acontece ao pedir um URL ou ao lançar um script pela consola? Cada um tem os seus limites.
3. Veja o código de resposta: um 500 costuma ser PHP; um 502 ou 504, o servidor web ou o proxy cansado de esperar.
4. Reproduza-o numa cópia, ativando o modo de depuração do PrestaShop, que mostra o erro no ecrã em vez de uma página em branco.
5. Confirme se cresce com os dados: se falha com um ano e não com um mês, o processo não trabalha por lotes.

Boas práticas para os processos longos

• Lance as tarefas pesadas pelo terminal, não através de um URL, sempre que o módulo o permita.
• Divida as importações grandes em ficheiros mais pequenos.
• Agende as tarefas pesadas fora das horas de tráfego e evite que duas coincidam.
• Use módulos que trabalhem por lotes e retomem onde ficaram se forem interrompidos.
• Mantenha o PrestaShop, o PHP e os módulos atualizados: as versões modernas do PHP consomem menos memória e são mais rápidas com o mesmo código.

Como resolver no PrestaShop

O RKR Sentinel avisa-o por Telegram quando a loja dá erros de memória esgotada, tempos esgotados, erros fatais ou respostas 500, com a mensagem, o ficheiro e a linha, um excerto do código, o rastreio, o URL e as versões, sem ter de ativar o modo de depuração em produção. Cada erro é agrupado pela sua impressão digital para que as repetições não lhe encham o chat. Se o problema estiver num processo que é preciso refazer para que trabalhe por lotes, ou em limites do servidor que não sabe onde se configuram, com um pacote de horas de suporte da Rekire diagnosticamo-lo numa cópia e corrigimo-lo.