O mistério do perfil do degrau da escada Recentemente, vimos , um serviço , exibir um comportamento estranho no que diz respeito ao uso de memória. Um perfil de memória de aparência estranha é a última coisa que eu esperaria de um programa Rust, mas aqui estamos nós. um de nossos projetos Rust axum O serviço seria executado com memória "plana" por um período de tempo e, de repente, saltaria para um novo patamar. Esse padrão se repetia ao longo de horas, às vezes sob carga, mas nem sempre. A parte preocupante foi que, quando vimos um aumento acentuado, era raro a memória cair de volta. Era como se a memória tivesse se perdido ou "vazado" de vez em quando. Em circunstâncias normais, esse perfil de "degrau" era apenas de aparência estranha, mas em um ponto o uso de memória aumentou desproporcionalmente. O crescimento ilimitado da memória pode forçar a saída dos serviços. Quando os serviços terminam abruptamente, isso pode diminuir a disponibilidade... o que é . Eu queria cavar e descobrir o que estava acontecendo. ruim para os negócios Normalmente, quando penso em crescimento inesperado de memória em um programa, penso em vazamentos. Ainda assim, isso parecia diferente. Com um vazamento, você tende a ver um padrão de crescimento mais estável e regular. Muitas vezes, isso parece uma linha inclinada para cima e para a direita. Então, se nosso serviço não estava vazando, o que ele estava fazendo? Se eu pudesse identificar as condições que causaram o salto no uso da memória, talvez pudesse mitigar o que estava acontecendo. Cavando Eu tinha duas perguntas candentes: Algo mudou em nosso código para promover esse comportamento? Caso contrário, surgiu um novo padrão de tráfego? Olhando para as métricas históricas, pude ver padrões semelhantes de aumentos acentuados entre longos períodos de estabilidade, mas nunca antes tivemos esse tipo de crescimento. Para saber se o crescimento em si era novo (apesar do padrão "degrau" ser para nós), eu precisaria de uma maneira confiável de reproduzir esse comportamento. normal Se eu pudesse forçar o "passo" a se mostrar, terei uma maneira de verificar uma mudança de comportamento quando tomar medidas para conter o crescimento da memória. Eu também seria capaz de retroceder em nosso histórico do git e procurar um ponto no tempo em que o serviço não exibisse um crescimento aparentemente ilimitado. As dimensões que usei ao executar meus testes de carga foram: O tamanho dos corpos POST enviados ao serviço. A taxa de solicitação (ou seja, solicitações por segundo). O número de conexões de cliente simultâneas. A combinação mágica para mim foi: e . corpos de solicitação maiores maior simultaneidade Ao executar testes de carga em um sistema local, existem todos os tipos de fatores limitantes, incluindo o número finito de processadores disponíveis para executar clientes e o próprio servidor. Ainda assim, consegui ver o "degrau" na memória da minha máquina local nas circunstâncias certas, mesmo com uma taxa de solicitação geral mais baixa. Usando uma carga útil de tamanho fixo e enviando solicitações em lotes, com um breve descanso entre elas, consegui aumentar a memória do serviço repetidamente, uma etapa por vez. Achei interessante que, embora pudesse aumentar a memória com o tempo, acabei atingindo um ponto de retornos decrescentes. Eventualmente, haveria algum teto (ainda muito maior do que o esperado) para o crescimento. Brincando um pouco mais, descobri que poderia atingir um teto ainda mais alto enviando solicitações com tamanhos de carga variados. Assim que identifiquei minha entrada, fui capaz de retroceder em nosso histórico do git, descobrindo que nosso susto na produção provavelmente não era o resultado de mudanças recentes de nossa parte. Os detalhes da carga de trabalho para acionar esse "degrau" são específicos do próprio aplicativo, embora eu tenha conseguido forçar um gráfico semelhante a acontecer com um . projeto de brinquedo #[derive(serde::Deserialize, Clone)] struct Widget { payload: serde_json::Value, } #[derive(serde::Serialize)] struct WidgetCreateResponse { id: String, size: usize, } async fn create_widget(Json(widget): Json<Widget>) -> Response { ( StatusCode::CREATED, Json(process_widget(widget.clone()).await), ) .into_response() } async fn process_widget(widget: Widget) -> WidgetCreateResponse { let widget_id = uuid::Uuid::new_v4(); let bytes = serde_json::to_vec(&widget.payload).unwrap_or_default(); // An arbitrary sleep to pad the handler latency as a stand-in for a more // complex code path. // Tweak the duration by setting the `SLEEP_MS` env var. tokio::time::sleep(std::time::Duration::from_millis( std::env::var("SLEEP_MS") .as_deref() .unwrap_or("150") .parse() .expect("invalid SLEEP_MS"), )) .await; WidgetCreateResponse { id: widget_id.to_string(), size: bytes.len(), } } Acontece que você não precisava de muito para chegar lá. Consegui ver um aumento acentuado semelhante (mas neste caso muito menor) de um aplicativo com um único manipulador recebendo um corpo JSON. axum Embora os aumentos de memória em meu projeto de brinquedo não tenham sido tão dramáticos quanto vimos no serviço de produção, foi o suficiente para me ajudar a comparar e contrastar durante a próxima fase de minha investigação. Também me ajudou a ter um loop de iteração mais rígido de uma base de código menor enquanto eu experimentava diferentes cargas de trabalho. Consulte o para obter detalhes sobre como executei meus testes de carga. README Passei algum tempo pesquisando na web relatórios de bugs ou discussões que pudessem descrever um comportamento semelhante. Um termo que surgiu repetidamente foi e depois de ler um pouco mais sobre o assunto, parecia que poderia se encaixar no que eu estava vendo. Heap Fragmentation O que é Fragmentação de Heap? Pessoas de certa idade podem ter tido a experiência de assistir a um no DOS ou mover blocos em um disco rígido para consolidar as áreas "usadas" e "livres". utilitário de desfragmentação no Windows No caso do disco rígido deste PC antigo, arquivos de tamanhos variados foram gravados no disco e depois movidos ou excluídos, deixando um "buraco" de espaço disponível entre outras regiões usadas. À medida que o disco começa a encher, você pode tentar criar um novo arquivo que não caiba em uma dessas áreas menores. No cenário de fragmentação de heap, isso levará a uma falha de alocação, embora o modo de falha da fragmentação de disco seja um pouco menos drástico. No disco, o arquivo precisará ser dividido em pedaços menores, o que torna o acesso muito menos eficiente (obrigado ). A solução para a unidade de disco é "desfragmentar" (desfragmentar) a unidade para reorganizar esses blocos abertos em espaços contínuos. wongarsu pela correção Algo semelhante pode quando o alocador (a coisa responsável por gerenciar a alocação de memória em seu programa) adiciona e remove valores de tamanhos variados ao longo de um período de tempo. As lacunas que são muito pequenas e espalhadas por todo o heap podem levar a novos blocos "novos" de memória sendo alocados para acomodar um novo valor que não caberia de outra forma. Embora, infelizmente, por causa de como o gerenciamento de memória funciona, uma "desfragmentação" não seja possível. acontecer A causa específica para a fragmentação pode ser uma série de coisas: análise JSON com , algo no nível do framework em , algo mais profundo em , ou mesmo apenas uma peculiaridade da implementação do alocador específico para o sistema em questão. Mesmo sem saber a causa raiz (se é que existe), o comportamento é observável em nosso ambiente e, de certa forma, reproduzível em um aplicativo básico. (Atualização: mais investigações são necessárias, mas temos certeza de que é a análise JSON, veja ews) serde axum tokio nosso comentário no HackerN Se isso é o que estava acontecendo com a memória do processo, o que pode ser feito a respeito? Parece que seria difícil mudar a carga de trabalho para evitar a fragmentação. Também parece que seria complicado desenrolar todas as dependências em meu projeto para possivelmente encontrar uma causa raiz no código de como os eventos de fragmentação estão ocorrendo. Então, o que pode ser feito? para o resgate Jemalloc é autodescrito como tendo como objetivo A simultaneidade era de fato uma parte do problema do meu programa, e evitar a fragmentação é o nome do jogo. parece que pode ser exatamente o que eu preciso. jemalloc "[enfatizar] a prevenção da fragmentação e o suporte à simultaneidade escalável". jemalloc Como é um alocador que se esforça para evitar a fragmentação em primeiro lugar, a esperança era que nosso serviço pudesse ser executado por mais tempo sem aumentar gradualmente a memória. jemalloc Não é tão trivial alterar as entradas do meu programa ou a pilha de dependências do aplicativo. No entanto, é trivial trocar o alocador. Seguindo os exemplos no leia-me , foi necessário muito pouco trabalho para fazer um test drive. https://github.com/tikv/jemallocator Para o meu , adicionei um recurso de carga para trocar opcionalmente o alocador padrão por e executei novamente meus testes de carga. projeto de brinquedo jemalloc A gravação da memória residente durante minha carga simulada mostra os dois perfis de memória distintos. Sem , vemos o familiar perfil do degrau da escada. Com , vemos a memória aumentar e diminuir repetidamente conforme o teste é executado. Mais importante, embora haja uma diferença considerável entre o uso de memória com durante o carregamento e os tempos ociosos, não "perdemos terreno" como fizemos antes, pois a memória sempre volta à linha de base. jemalloc jemalloc jemalloc Empacotando Se acontecer de você ver um perfil de "degrau" em um serviço Rust, considere fazer um teste de . Se você tiver uma carga de trabalho que promova a fragmentação do heap, pode fornecer um resultado geral melhor. jemalloc jemalloc Separadamente, incluído no repositório está um para uso com a ferramenta de teste de carga . Tente alterar a simultaneidade, o tamanho do corpo (e a duração arbitrária da suspensão do manipulador no próprio serviço), etc., para ver como a alteração no alocador afeta o perfil de memória. do projeto de brinquedo benchmark.yml https://github.com/fcsonline/drill Quanto ao impacto no mundo real, você pode ver claramente a mudança de perfil quando implementamos a mudança para . jemalloc Onde o serviço costumava mostrar linhas planas e etapas grandes, geralmente independentemente da carga, agora vemos uma linha mais irregular que segue mais de perto a carga de trabalho ativa. Além do benefício de ajudar o serviço a evitar o crescimento desnecessário de memória, essa alteração nos deu uma visão melhor de como nosso serviço responde à carga, portanto, no geral, esse foi um resultado positivo. Se você tem interesse em construir um serviço robusto e escalável usando Rust, estamos contratando! Confira para mais informações. nossa página de carreiras Para mais conteúdo como este, siga-nos no , ou para obter as atualizações mais recentes do , ou participe da discussão em . Twitter Github RSS serviço webhook Svix nossa comunidade Slack Também publicado aqui.
