Ajuste de Spill no Object Store do Ray Core: Fim do OOM

O ajuste de spill no object store do Ray Core impede a queda de nós quando picos de memória paralisam o processamento. Quando workers distribuídos processam cargas massivas sem gerenciamento ativo do object store, a memória compartilhada do Plasma atinge o limite máximo, forçando o killer Out-Of-Memory do Linux a encerrar abruptamente os processos raylet e corromper o progresso das tarefas. Cargas de trabalho em produção que executam tokenização de texto e transformações de tensores frequentemente entram em deadlock devido a referências de objetos não monitoradas e destinos de spill não otimizados.

Para restabelecer a estabilidade em clusters multi-nó que processam grandes volumes de dados corporativos, as equipes de engenharia devem abandonar premissas puramente em memória e adotar estratégias explícitas de offloading para disco. A implementação de políticas estruturadas de despejo, o isolamento de diretórios temporários em discos NVMe locais e a liberação imediata de ponteiros Python previnem a queda de workers enquanto mantêm o throughput máximo da pipeline.

Por Que o Ray Core Faz Spill da Memória Compartilhada do Plasma para o Disco

O Ray utiliza o Plasma, um armazenador de objetos compartilhados em memória alocado em cada nó do cluster. Quando uma tarefa gera saídas ou envia dados via ray.put(), esses artefatos residem no repositório Plasma local. Como o Plasma opera como um segmento de memória compartilhada de tamanho fixo—geralmente limitado a 30% da RAM total do sistema—tarefas intensivas podem consumir o espaço disponível muito mais rápido do que as rotinas de garbage collection conseguem liberar.

Quando a demanda de memória excede a capacidade do Plasma, o Ray aciona seu protocolo de spill. Se nenhum local externo estiver configurado ou se o disco local atingir um gargalo de taxa de transferência, os processos workers sofrem uma forte pressão de retrocarga. Em arquiteturas de dados em fluxo contínuo, como as que sustentam o nosso RAG Knowledge Base Pipeline, a saturação do Plasma gera descalibragens catastróficas e reexecuções em cadeia no cluster.

Diferente de motores SQL distribuídos analisados em nosso artigo sobre DuckDB Out-of-Core Memory Spills, o Ray gerencia estruturas complexas em Python, arrays NumPy e tabelas Arrow. Esse modelo flexível cria riscos de retenção indesejada. Se uma única tarefa mantiver uma referência ativa para um ObjectRef, o Plasma marca aquele bloco como não removível. Quando esses objetos retidos se acumulam junto ao fluxo de dados, o Plasma é obrigado a despejar os objetos restantes para o armazenamento secundário ou interromper o cluster em caso de falha de disco.

Diagnosticando Spills com Métricas do Prometheus e Ray Dashboard

Identificar se o gargalo de desempenho decorre da pressão de memória no Plasma ou do transporte de rede exige o acompanhamento rigoroso de métricas operacionais. O Ray expõe telemetria detalhada via OpenTelemetry e Prometheus, garantindo visibilidade sobre o ciclo de vida dos objetos e a latência de gravação em disco.

As métricas cruciais durante picos de ingestão incluem:

1. ray_object_store_memory: Mede os bytes ativos ocupados no Plasma em relação ao limite do nó.
2. ray_object_store_spilled_bytes_total: Contador incremental que registra o volume total de bytes transferidos para o disco.
3. ray_memory_usage_bytes: Uso de memória RSS em tempo real nos processos workers em Python.
4. ray_component_cpu_percentage: Identifica se as threads de serialização de I/O estão bloqueando o agendamento de tarefas.

Quando a métrica ray_object_store_spilled_bytes_total cresce rapidamente enquanto o throughput cai, o cluster está enfrentando um gargalo severo de I/O de disco. Esse cenário ocorre quando os workers tentam ler objetos do spill em volumes EBS lentos ou armazenamentos em nuvem mais rápido do que a infraestrutura consegue entregar. Mapear esses dados junto às métricas de IOPS do nó permite ajustar a capacidade de concorrência com precisão.

Configurando Políticas Híbridas de Storage para NVMe Local e Cloud Storage

Para resolver a saturação do Plasma, é necessário configurar explicitamente os diretórios de spill nas opções do sistema Ray. Por padrão, o Ray tenta gravar arquivos temporários no diretório /tmp/ray/spill, que geralmente está localizado no volume de inicialização do sistema operacional. Volumes de disco raiz em instâncias de nuvem raramente possuem IOPS suficientes para sustentar gravações simultâneas de vários gigabytes.

Em ambientes de alto desempenho, deve-se adotar uma arquitetura de spill em camadas: a primeira camada utiliza discos NVMe locais de altíssima velocidade anexados à instância, enquanto a segunda camada utiliza buckets S3 ou Google Cloud Storage para estouros de grande volume. O código Python a seguir ilustra como inicializar o Ray definindo alvos híbridos de spill programaticamente.