Existe uma categoria de uso do Python que raramente aparece em conteúdo sobre hospedagem: rotinas que não atendem visitantes.

Um script que consolida dados de vendas toda madrugada. Uma integração que busca informações de um sistema e alimenta outro. Uma rotina que gera relatórios, processa planilhas, limpa bases ou treina um modelo.

Essas rotinas têm um perfil de consumo oposto ao de uma aplicação web — e por isso o que se sabe sobre dimensionar sites não se aplica bem a elas. Este guia trata do que muda.

O perfil de carga é invertido

Comece por aqui, porque explica todas as decisões seguintes.

Uma aplicação web tem carga distribuída: muitas operações pequenas ao longo do dia, cada uma consumindo pouco. O dimensionamento olha para o pico de simultaneidade.

Uma rotina de dados faz o contrário: fica ociosa a maior parte do tempo e consome muito durante a execução.

	Aplicação web	Rotina de dados
Padrão de uso	Contínuo	Concentrado em janelas
Operações	Muitas e pequenas	Poucas e grandes
Recurso crítico	Simultaneidade	Memória no pico
Duração	Milissegundos	Minutos ou horas
Efeito de uma falha	Um usuário afetado	Rotina inteira perdida
Média de consumo	Representativa	Enganosa

A última linha é a que mais leva a erro de dimensionamento: um servidor com média confortável pode estar saturando completamente durante as janelas de execução. Medir a média de um ambiente com rotinas de dados é medir a coisa errada.

Memória: o limite que aparece primeiro

O gargalo mais comum e o que mais derruba rotinas.

O padrão que causa o problema é conhecido: carregar tudo na memória de uma vez. Ler um arquivo inteiro, trazer todos os registros de uma consulta, montar uma estrutura completa antes de processar.

Funciona durante o desenvolvimento, com uma amostra pequena. Quebra em produção, quando o volume real aparece — e o sintoma é o processo sendo encerrado pelo sistema operacional, frequentemente sem mensagem clara.

O que resolve, em ordem de eficácia:

1. Processar em partes. Ler e tratar blocos de registros em vez do conjunto inteiro reduz o consumo em ordens de grandeza.
2. Deixar o trabalho no banco de dados, quando possível. Agregar, filtrar e somar no banco é muito mais eficiente que trazer tudo para a memória e fazer isso fora.
3. Liberar o que já foi usado, evitando acumular estruturas intermediárias ao longo da rotina.
4. Usar tipos de dados adequados, já que representações mais econômicas reduzem consideravelmente o consumo em conjuntos grandes.
5. Gravar resultados parciais, para que uma falha no meio não perca o trabalho já feito.

O item 2 é o mais subestimado e o que mais economiza: uma consulta que já devolve o resultado agregado evita carregar milhões de registros. É comum encontrar rotinas que trazem a base inteira para calcular uma soma.

E o item 5 tem valor operacional além da memória: uma rotina de duas horas que falha aos noventa minutos e recomeça do zero custa muito mais que uma que retoma de onde parou.

Agendamento: mais difícil do que parece

Rotinas de dados quase sempre rodam em horários definidos, e o agendamento tem armadilhas próprias.

Sobreposição

Se uma rotina agendada a cada hora demora setenta minutos, a próxima começa antes de a anterior terminar. Duas execuções simultâneas competem por recursos, podem corromper resultados e frequentemente derrubam o servidor.

A proteção é um mecanismo que impede a segunda execução enquanto a primeira está ativa — e um alerta quando isso acontece, porque indica que a rotina cresceu além da janela.

Concentração

É comum agendar tudo para a madrugada, e igualmente comum agendar tudo para o mesmo minuto. Cinco rotinas pesadas começando juntas produzem um pico desnecessário, quando escaloná-las em intervalos resolveria sem custo.

Dependência entre rotinas

Quando uma rotina depende do resultado de outra, agendar por horário é frágil: se a primeira atrasar, a segunda roda com dados incompletos — e não avisa.

A saída é encadear explicitamente: a segunda começa quando a primeira termina com sucesso, não em um horário fixo.

Fuso e horário de verão

Um detalhe que gera incidentes reais. Definir o fuso do servidor explicitamente evita que rotinas rodem em horário inesperado, e vale conferir o comportamento de rotinas agendadas em horários que podem ser afetados por mudanças de horário oficial.

Quando a rotina precisa de uma fila

Nem toda rotina de dados é agendada. Algumas são disparadas por uma ação — um usuário pede um relatório, envia uma planilha para importação, solicita uma exportação.

Nesses casos, o padrão correto é registrar a tarefa e processá-la em segundo plano, com o usuário acompanhando o progresso. O conceito e os requisitos estão no artigo sobre o que é uma fila de tarefas.

Duas observações específicas para processamento de dados:

• Os trabalhadores que executam essas tarefas consomem muito mais memória que os que atendem requisições, porque cada tarefa pode carregar volumes grandes. Dimensioná-los igual subestima o consumo — ponto já registrado no artigo sobre dimensionar um servidor para aplicações Python.
• Vale separar filas por peso. Tarefas rápidas e tarefas pesadas na mesma fila fazem as rápidas esperarem atrás de uma importação de uma hora.

A separação de filas é uma medida simples com efeito grande na percepção do usuário: um relatório rápido não deveria ficar na fila atrás de um processamento longo.

Armazenamento e arquivos intermediários

Um aspecto que aparece pouco e derruba servidores com frequência.

Rotinas de dados geram arquivos: extrações, resultados parciais, exportações, arquivos temporários de bibliotecas. Sem limpeza, eles se acumulam até encher o disco — e disco cheio derruba a aplicação e o banco de dados juntos.

O que evita:

• Limpeza ao final da rotina, inclusive em caso de erro.
• Política de retenção para resultados que precisam ser guardados.
• Monitoramento do espaço, com alerta antes do limite.
• Armazenamento separado para arquivos grandes, quando o volume justificar.
• Atenção aos arquivos temporários, que algumas bibliotecas criam e não removem em caso de falha.

O último item é a causa mais frequente: uma rotina que falha no meio deixa temporários para trás, e a repetição diária desse comportamento enche o disco em semanas.

O banco de dados sob rotinas pesadas

Um ponto de atenção quando a rotina lê ou escreve em um banco compartilhado com a aplicação.

Consultas pesadas de processamento competem com as consultas que atendem usuários. O resultado é uma aplicação lenta durante a janela da rotina, sem que nada esteja errado com a aplicação.

O que ajuda:

1. Executar em janelas de menor uso, o que já resolve boa parte.
2. Processar em lotes, com pausas, em vez de uma operação contínua longa.
3. Evitar operações que bloqueiem tabelas usadas pela aplicação.
4. Considerar uma cópia para leitura quando o volume justificar, isolando o processamento da operação.
5. Escrever em lotes, já que inserções individuais em massa são muito mais lentas e custosas.

O item 3 merece atenção em bancos com tabelas grandes: uma operação que bloqueia uma tabela por alguns minutos pode significar checkout travado em uma loja, como tratamos no artigo sobre banco de dados em lojas grandes.

Monitorar o que roda sozinho

Rotinas de dados compartilham a característica mais perigosa da automação: falham em silêncio.

Ninguém percebe que o relatório de terça não foi gerado até alguém procurar por ele. E se a rotina alimenta outro sistema, os dados desatualizados se propagam sem aviso.

O que acompanhar:

• Execução concluída com sucesso, e não apenas iniciada.
• Duração de cada execução, cujo crescimento indica volume aumentando.
• Volume processado, porque uma rotina que conclui com sucesso processando zero registros está falhando de outra forma.
• Consumo de memória no pico, para agir antes do limite.
• Espaço em disco.
• Alerta em caso de falha e, idealmente, em caso de ausência de execução.

O terceiro item é o mais valioso e o menos implementado: uma rotina pode terminar sem erro e não ter feito nada — porque a origem estava vazia, a consulta retornou sem resultados ou uma condição impediu o processamento. Verificar o volume detecta isso; verificar o código de conclusão, não.

E o último merece destaque: alertar quando uma rotina não roda é diferente de alertar quando ela falha. Se o agendador parou, não há falha para reportar — há apenas ausência.

Conclusão

Rotinas de processamento têm perfil de carga invertido em relação a aplicações web: ficam ociosas e consomem muito em janelas concentradas. Isso torna a média de consumo enganosa e faz da memória no pico o recurso crítico.

Duas práticas resolvem a maior parte dos problemas: processar em partes em vez de carregar tudo na memória, e deixar o trabalho de agregação no banco de dados em vez de trazer os registros para fora. Juntas, elas costumam reduzir o consumo em ordens de grandeza.

E no monitoramento, uma verificação que quase ninguém faz: acompanhar o volume processado, e não apenas se a rotina terminou sem erro. Uma execução bem-sucedida que processou zero registros é uma falha silenciosa. Conheça o Cloud Server para Python da TBF Host e avalie o ambiente adequado às suas rotinas.

Perguntas frequentes

Por que rotinas de dados exigem um dimensionamento diferente?

Porque o perfil de carga é invertido: elas ficam ociosas a maior parte do tempo e consomem muito durante as janelas de execução. A média de consumo é enganosa — um servidor com média confortável pode estar saturando completamente durante o processamento.

Minha rotina Python é encerrada sem mensagem clara. O que pode ser?

Provavelmente memória esgotada, com o processo sendo encerrado pelo sistema operacional. A causa mais comum é carregar tudo de uma vez: ler um arquivo inteiro ou trazer todos os registros de uma consulta antes de processar. Processar em partes reduz o consumo em ordens de grandeza.

Como reduzir o consumo de memória em processamento de dados?

Processando em blocos em vez do conjunto inteiro, deixando agregações e filtros no banco de dados em vez de trazer tudo para fora, liberando estruturas intermediárias, usando tipos de dados mais econômicos e gravando resultados parciais para não perder o trabalho em caso de falha.

O que acontece se uma rotina agendada demorar mais que o intervalo?

A próxima execução começa antes de a anterior terminar. Duas execuções simultâneas competem por recursos, podem corromper resultados e frequentemente derrubam o servidor. É preciso um mecanismo que impeça a sobreposição e um alerta quando ela for detectada.

Como lidar com rotinas que dependem umas das outras?

Encadeando explicitamente em vez de agendar por horário: a segunda começa quando a primeira termina com sucesso. Agendar por horário é frágil — se a primeira atrasar, a segunda roda com dados incompletos e não avisa ninguém.

Por que o site fica lento quando minha rotina roda?

Porque as consultas pesadas de processamento competem com as que atendem usuários no mesmo banco. Executar em janelas de menor uso, processar em lotes com pausas, evitar operações que bloqueiem tabelas e, quando o volume justificar, usar uma cópia para leitura resolve.

Como saber se uma rotina de dados está funcionando?

Acompanhando a conclusão com sucesso, a duração de cada execução, o consumo de memória no pico e, principalmente, o volume processado. Uma rotina pode terminar sem erro e não ter feito nada, porque a origem estava vazia ou uma condição impediu o processamento.

Rotinas de dados podem encher o disco?

Sim, e é uma causa frequente de queda. Elas geram extrações, resultados parciais e arquivos temporários — e algumas bibliotecas não removem os temporários em caso de falha. A repetição diária desse comportamento enche o disco em semanas, derrubando aplicação e banco juntos.