Os engenheiros do Google começaram a postar neste mês novos patches para o subsistema de gerenciamento de memória do Linux e componentes relacionados para um recurso chamado Working Set Reporting.
A funcionalidade de relatório do conjunto de trabalho baseia-se no MGLRU e destina-se a lidar melhor com VMs ou contêineres supercomprometidos. A recente série de patches RFC resume as coisas como:
Histórico
==========
Para clientes e servidores, as cargas de trabalho podem ser conteinerizadas com máquinas virtuais, contêineres kubernetes ou memcgs. As cargas de trabalho diferem entre servidores e clientes.
Os trabalhos de servidor têm pegadas de memória mais previsíveis e preocupam-se com a estabilidade e o desempenho. Uma técnica é a recuperação proativa, que recupera a memória antes da pressão da memória e torna aparente a quantidade de memória realmente livre em uma máquina.
Os aplicativos cliente são mais intermitentes e imprevisíveis, pois reagem às interações do usuário. O sistema precisa responder rapidamente a eventos interessantes e estar ciente do uso de energia.
Uma máquina sobrecarregada pode dimensionar a pegada dos contêineres por meio de memory.max/high, virtio-balloon, etc.
O dispositivo de balão é um mecanismo típico para compartilhar memória entre uma VM convidada e um host. É particularmente útil em cenários de várias VMs em que a memória é supercomprometida e são necessárias alterações dinâmicas no tamanho da memória da VM conforme as cargas de trabalho mudam no sistema. O dispositivo de balão agora tem vários recursos para auxiliar no compartilhamento criterioso de recursos de memória entre os convidados e o host (por exemplo, sugestões de páginas gratuitas, estatísticas, relatórios de páginas gratuitas). Para um programa de controlador de host encarregado de otimizar os recursos de memória em um ambiente multi-VM, ele deve usar essas ferramentas para responder a duas perguntas concretas:
1. Quando é o momento certo para modificar o balão?
2. Quanto deve ser trocado o balão?
Um projeto inicial para desenvolver esse recurso de "balão automático" foi realizado em 2013. Mais recentemente, foram criados dispositivos VIRTIO adicionais (virtio-mem, virtio-pmem) que oferecem mais ferramentas para vários casos de uso, cada um com vantagens e desvantagens. Uma proposta anterior para estender o MGLRU com interfaces de conjunto de trabalho se concentra nos casos de uso do servidor, mas não funciona para os clientes
Proposta
==========
Uma estrutura de relatórios unificada do conjunto de trabalho que funciona para servidores e clientes. Ele envolve histogramas por nó no host, histogramas por memória e uma extensão de driver virtio-balloon.
Há duas maneiras de trabalhar com relatórios de conjunto de trabalho: orientado a eventos e consulta. O controlador de host pode receber notificações de recuperação, que produz um relatório, ou o controlador pode consultar o histograma diretamente.
O Patch 1 apresenta o mecanismo de relatórios do conjunto de trabalho e as interfaces do host.
Consulte a seção Detalhes para o Patch 2 que estende o driver virtio-balloon com relatórios do conjunto de trabalho.
O RFC inicial baseia-se no MGLRU e destina-se a ser uma prova de conceito para discussão e refinamentos. TJ e eu pretendemos dar suporte ao LRU ativo/inativo e à estimativa do conjunto de trabalho do espaço do usuário. Estamos trabalhando em scripts de demonstração e obtendo alguns números também.
Além das mudanças no gerenciamento de memória do kernel do Linux, há patches QEMU para o VirtIO Balloon para adicionar o recurso Relatório do conjunto de trabalho.
"O caso de uso é um host com memória superalocada e 1 ou mais VMs. O objetivo é obter informações oportunas e precisas sobre a utilização geral da memória para conduzir atividades de recuperação apropriadas, já que em alguns casos de uso de dispositivo cliente, uma VM pode precisar de um fração significativa da memória geral por um período de tempo, mas depois entra em um período de silêncio que resulta em um grande número de páginas frias no convidado.
O dispositivo de balão agora tem vários recursos para auxiliar no compartilhamento de recursos de memória entre os convidados e o host (por exemplo, sugestões de páginas gratuitas, estatísticas, relatórios de páginas gratuitas). Conforme mencionado no slide 12 em [1], o balão não possui um bom mecanismo para conduzir a recuperação do cache do convidado. Nosso caso de uso inclui cache de página típico, bem como "caches de aplicativos" com memória que deve ser descartada em momentos de pressão de memória em todo o sistema. Em alguns casos, o virtio-pmem pode ser um método para controle do host do cache do convidado, mas há implicações de segurança indesejáveis."
E há também a proposta de atualização de especificação do VirtIO que foi enviada na semana passada para discussão.
Ou, para uma visão geral mais fácil dessa funcionalidade de relatório do conjunto de trabalho, os engenheiros do Google envolvidos compartilharam conosco os slides de sua palestra LSF/MM/BPF 2023 sobre esse recurso proposto:
Até a próxima !!
Nenhum comentário:
Postar um comentário