Cgroup memory.usage_in_bytes mostra o valor incorreto

0

Eu criei um Cgroup no meu dispositivo Linux e notei que o valor da memória .usage_in_bytes (4325376) é maior que a soma de RSS, CACHE e SWAP (4194304).

Eu li em uma documentação confiável , o memory.usage_in_bytes não é exibido o valor exato do uso de memória (e swap). Se você quiser saber o uso mais exato da memória, você deve usar o valor RSS + CACHE (+ SWAP) em memory.stat.

Alguém tem idéia sobre isso? Devo usar o valor de memory.usage_in_bytes?

    
por DOAN MINH HUNG 22.06.2018 / 10:36

1 resposta

0

usage_in_bytes

For efficiency, as other kernel components, memory cgroup uses some optimization to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz value for efficient access. (Of course, when necessary, it's synchronized.) If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) value in memory.stat(see 5.2).

Se você estiver lendo os arquivos precisos repetidamente, e você mediu o desempenho do seu sistema como sendo limitado pelo uso da CPU, você pode considerar a amostragem memory_usage.

Eu não sei como funciona. No entanto, como um leitor LWN.net, isso soa semelhante a uma situação em que pode haver vários contadores que são mantidos locais para onde eles são usados e onde de alguma forma a leitura de usage_in_bytes não força uma sincronização imediata e um resumo desses contadores. >

Over the years, kernel developers have made increasing use of per-CPU data in an effort to minimize memory contention and its associated performance penalties. As a simple example, consider the disk operation statistics maintained by the block layer. Incrementing a global counter for every disk operation would cause the associated cache line to bounce continually between processors; disk operations are frequent enough that the performance cost would be measurable. So each CPU maintains its own set of counters locally; it never has to contend with any other CPU to increment one of those counters. When a total count is needed, all of the per-CPU counters are added up. Given that the counters are queried far more rarely than they are modified, storing them in per-CPU form yields a significant performance improvement.

- link

Se você tiver um sistema pequeno - não um grande número de CPUs, e não manter um grande número de cgroups - a sobrecarga não parece muito significativa. Não custa muito ressaltar algumas linhas de cache entre processadores. Mas a eficiência pode ser útil se você for o Google e estiver executando milhares de contêineres em um sistema :) ou se tiver algum sistema com milhares de CPUs.

    
por 22.06.2018 / 13:25