Qual métrica de memória alertas e autoscalers devem usar em um serviço conteinerizado: RSS, PSS, working set ou memory.current do cgroup?

Pergunta em aberto

Os números disponíveis divergem sobre quanto um contêiner "usa". A man page define o VmRSS de um processo como a soma de RssAnon, RssFile e RssShmem; portanto, ele inclui páginas associadas a arquivos que o kernel pode recuperar e conta as páginas compartilhadas uma vez para cada processo. A documentação do cgroup v2 define memory.current como a quantidade total de memória em uso no momento pelo cgroup e seus descendentes, e o memory.stat detalha esse total em memória anônima, cache de arquivos (incluindo tmpfs e memória compartilhada) e memória do kernel; é sobre esse total que atuam o memory.max e o OOM killer. A documentação do Kubernetes informa a memória como working set, descreve como ideal a memória em uso que não pode ser liberada sob pressão e afirma que o cálculo varia conforme o sistema operacional do host, depende fortemente de heurísticas e normalmente inclui parte da memória associada a arquivos.

Em um serviço de longa duração com limite de memória, qual dessas métricas deve acionar um alerta ou um autoscaler? Um alerta baseado em RSS pode não detectar um contêiner que se aproxima do limite, porque o page cache e a memória do kernel são contabilizados no cgroup, mas não no processo. Um alerta baseado em memory.current pode disparar para um contêiner cujo cache seria simplesmente recuperado. O working set fica entre os dois, mas a documentação diz que seu cálculo varia conforme o sistema operacional do host e depende fortemente de heurísticas. Subperguntas:

• Qual sinal foi usado na prática por um ano ou mais, e com que frequência gerou alertas falsos em comparação com OOM kills não detectados?
• Um serviço que lê arquivos grandes pelo page cache (bancos de dados, mídia, coletores de logs) precisa de um sinal diferente do de um serviço que mantém seu estado em memória anônima?
• A grandeza relevante é de fato um nível, ou seria a taxa de crescimento da memória anônima, ou ainda as informações de pressure stall de memória, que medem o tempo perdido com recuperação de memória em vez de bytes?
• Como ajustar o sinal para serviços que preenchem a memória com cache de forma deliberada até o limite?

O que uma resposta útil contém

Os nomes exatos das métricas e suas fontes (qual arquivo em /proc ou do cgroup, qual métrica do runtime), o tipo de carga de trabalho, a configuração de limite, por quanto tempo a regra esteve em uso, a contagem de alertas e de OOM kills nesse período, indicando quantos de cada foram justificados, e o raciocínio que liga a métrica escolhida à condição de OOM. Respostas que comparam dois sinais no mesmo serviço e no mesmo período são mais úteis do que as que descrevem um único sinal; respostas que repetem os padrões do fornecedor devem deixar isso claro.