Introdução

Eventos de falta de memória (OOM) são comuns no ambiente Linux quando há programas que alocam muita memória. Redpanda é um desses programas, pois usa o
Estrela do Mar
biblioteca, que tenta utilizar todo o hardware até seus limites.

Há uma funcionalidade especial do kernel, chamada Out Of Memory Killer (OOM Killer), que ajuda a manter as máquinas Linux operacionais, matando o maior processo com a menor prioridade. O OOM Killer pode reconhecer e respeitar processos que possuem restrições no Linux cgroups.

A menos que você especifique os parâmetros de entrada, o Redpanda lê a memória disponível no hardware e reserva pelo menos 1,5 GiB para o sistema operacional (SO) e divide o restante igualmente para cada núcleo da máquina para maximizar a eficiência do alocador de memória Seastar. Se o Redpanda estiver sendo executado junto com outros programas, o sistema operacional Linux pode ficar sem memória.

Se você também teve problemas com o OOM Killer, continue lendo para saber como resolvemos nossos problemas com ele para que você possa fazer o mesmo.

Como OOM Killer começou a interromper nosso sidecar

Quando começamos a ter problemas com o OOM Killer, o Redpanda Cloud usava (e ainda usa) Kubernetes (K8s) e confiou em cgroups e namespaces Linux para restringir as cargas de trabalho. Se o Redpanda não fosse informado sobre quais parâmetros de memória ele deveria escolher, então a biblioteca Seastar subjacente alocaria 1,5 GiB para o sistema operacional, e o restante do cgroup seria dividido entre o número de núcleos de CPU disponíveis.

Tal configuração não fazia sentido para um ambiente em contêiner onde o Redpanda estava isolado de qualquer outro processo. Os usuários hipotéticos do operador Redpanda não devem se preocupar em como configurar os parâmetros avançados de memória do Redpanda, mas, dependendo da capacidade desejada, os nós K8s adequados devem estar disponíveis para o Redpanda e os limites e solicitações corretos precisam ser definidos. O primeiro dimensionamento para o pod Redpanda em K8s reservou 0,5 GiB de memória para os outros pods executados em um nó Redpanda dedicado.

Para automatizar e facilitar a implantação do Redpanda K8s, criamos um operador. A fim de restringir Redpanda e alavancar cgroup capacidade, fornecemos uma opção de configuração de recurso no recurso personalizado de cluster. Essa configuração foi mapeada diretamente para a configuração do Redpanda para que o Redpanda pudesse usar toda a memória disponível para o contêiner.

Em nossa primeira implementação do operador Redpanda, o recurso de implantação K8s foi configurado para não substituir o ponto de entrada do contêiner. O ponto de entrada padrão aproveitado
supervisionado
para agendar processos Redpanda, relatórios de telemetria e coprocessadores WebAssembly (Wasm). Essa simplificação desempenhou um papel nas implantações do ambiente local (por exemplo, docker run).

Quando o Redpanda aqueceu seu cache, OOM Killer viu essa memória dentro do Redpanda cgroup estava exausto e matou o maior processo Redpanda. Os usuários veriam que o broker estava indisponível até que o tempo de execução do contêiner reiniciasse o processo Redpanda. O operador Redpanda poderia automatizar a mesma função que o supervisord agendando apenas um processo dentro de um contêiner, e o tempo de execução do contêiner faria o trabalho pesado e isolaria cada processo. A depuração de outros problemas foi facilitada pelo fato de que o OOM Killer reconheceu processos individuais e apenas aqueles foram afetados.

A primeira solução que tentamos para resolver os eventos OOM Killer envolveu a implantação do K8s, onde cada processo estava sendo executado em seu próprio contêiner dedicado. Ao investigar esta solução potencial, vimos que rpk debug info, que envia dados de telemetria, foi executado a cada 10 minutos. O problema era que o Redpanda tinha uma carga maior do que o normal, e nosso sidecar usava mais memória do que o definido em cgroup. Então o OOM Killer começou a matar esse container sidecar.

Em seguida, a equipe de nuvem otimizou a solução gerenciada, então eliminamos todos os sidecars da implantação. A telemetria foi movida para fora do pod Redpanda e os coprocessadores Wasm foram desativados até o GA. Com apenas um processo Redpanda em execução no pod, a memória cgroup restrições foram mapeadas para a memória do Redpanda. Em clusters de longa duração, a alocação de memória cresceu a ponto de, do ponto de vista do sistema operacional, toda a memória disponível ser consumida pelo Redpanda. Os processos foram novamente mortos pelo OOM Killer. Neste ponto, estávamos procurando por um bug no Redpanda, mas acontece que a implementação do pod K8s é apoiada por
um recipiente de pausa
.

Resolvendo o desafio OOM Killer

Para criar um sandbox de contêiner e poder reiniciar contêineres individuais em uma configuração de pod de vários contêineres, os processos de pausa desempenham um papel crucial para orquestrar outros processos. Olhando para o código-fonte, esse processo pode parecer não ser tão grande em termos de memória, mas precisa de uma página do sistema operacional apenas para funcionar. Esta página desempenha um papel fundamental quando o OOM Killer verifica todos cgroupse descobre que o contêiner Redpanda estoura seu uso de memória.

Depois que o relatório do OOM Killer provou que o contêiner de pausa estava listado no processo Redpanda, implementamos a reserva de memória para resolver esse problema. Com um único contêiner, não conseguimos alocar toda a memória para o processo Redpanda.
O operador Redpanda estende
definição de recurso personalizado de cluster para incluir a configuração de recurso Redpanda. Agora, cgroup a memória não está apertada com a alocação máxima de memória do Redpanda. Dependendo do tamanho do nó do trabalhador K8s e do tráfego em particular, os clientes do nó podem atribuir menos memória ao Redpanda em comparação ao contêiner.

A próxima melhoria que fizemos para resolver nossos problemas com o OOM Killer foi
adicionar 10% de reserva de memória padrão
ao SO. Isso foi feito para evitar a pressão de memória em nós do trabalhador K8s superprovisionados. Se os usuários do operador Redpanda não configurassem a memória Redpanda, então – em clusters grandes o suficiente onde todo o limite de memória fosse distribuído entre todos os pods – os clientes poderiam observar eventos de pressão de memória. Com picos de tráfego e uso de clientes Kafka, a equipe do SRE pode observar que a reserva de host de memória kubelet padrão não é suficiente para o sistema operacional. Essa mitigação de reserva de memória de 10% foi implementada para ajudar os clientes que já usavam o operador Redpanda. Uma atualização do operador recalcularia a reserva de memória necessária. Essa solução, em vez disso, dá espaço para um contêiner de pausa e outras estruturas de dados do kernel necessárias para que o nó K8S funcione corretamente.

Otimizando o consumo de recursos em máquinas maiores

Nos clusters maiores (por exemplo, 16 núcleos e 64 GiB), o Redpanda precisa dar mais espaço aos serviços auxiliares. Cada núcleo será ocupado pelo fragmento Redpanda. Esse fragmento não sobrecarrega o sistema de métricas ou o agregador de log, mas, quando multiplicado pelo número de núcleos, pode alterar significativamente os requisitos de recursos (por exemplo, Prometheus para métricas ou FluentBit para log). Enquanto o OOM Killer estava analisando os maiores processos com a menor prioridade dentro de cada cgroup, Redpanda foi escolhido para ser encerrado. O exportador de nó K8s começou a relatar eventos de pressão de memória de nó. Para nossas maiores implantações, ajustamos a memória para deixar mais espaço para

logging collector, kubelet, node-exportere kube-proxy.

Ironicamente, o que é interessante é que, para evitar a morte do Redpanda por OOM, reduzimos a quantidade de memória usada pelo Redpanda. Em primeiro lugar, reduzindo a quantidade de memória alocada para o cgroupe, em seguida, reduzindo a quantidade de memória que o Seastar pode usar dentro desse cgroup.

Como ajustar a alocação de memória padrão

Apesar de encontrar esses desafios com o OOM Killer, conseguimos solucionar esses problemas de uso de memória com eficiência. Agora estamos mais atentos às restrições de recursos em um ambiente em contêiner. Todas as melhorias foram feitas em nossa pilha de observabilidade e no operador Redpanda para facilitar a experiência de depuração da perda de nós Redpanda.

Para qualquer usuário do operador Redpanda, o mais importante é entender que, por padrão, o operador atribuirá 10% das solicitações de recursos K8s fornecidas.

Se os usuários quiserem alterar o limite de 10% na seção de recursos personalizados do cluster, eles devem calcular solicitações, limites e opções do Redpanda para corresponder à configuração desejada:

yaml kind: Cluster spec: resources: requests: cpu: 2 memory: 2.23Gi redpanda: cpu: 2 memory: 2Gi limits: cpu: 2 memory: 2.23Gi

Se eles não precisarem alterar a almofada de memória de 10%, a seção Redpanda pode ser omitida.

Não só deve o cgroup ser levado em consideração, mas também deve ser o esgotamento geral dos recursos de memória no nó K8s.

Conclusão

Ao otimizar a sobrecarga do ambiente em contêiner, podemos fornecer uma experiência de nuvem melhor gerenciada e atender nossos usuários onde quer que estejam em sua jornada de aplicativos de streaming.

Para obter mais informações sobre como usar o Redpanda no Linux, veja nossa documentação. Saiba mais sobre Redpanda em
nosso repositório GitHub
ou
participe da nossa comunidade Slack
interagir diretamente com nossos engenheiros e equipe.


Source link

Previous articleDownload – Porto Theme v6.4.0 Nulled | Iptv
Next articleO PROCESSO DE TRANSFORMAÇÃO – pt.Jesus.net

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.