Похоже, это работает, по крайней мере, на примере предоставленных вами данных:
sed -'s/^ .*{/{/' file
Он преобразует первую строку каждого блока "имя" {
(обратите внимание на начальный пробел) до {
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).
Если вы повторно читаете точные файлы, и вы определили, что производительность вашей системы ограничена использованием ЦП, вместо этого вы можете рассмотреть возможность выборки _использования памяти.
Я не знаю, как это работает. Однако, как читатель LWN.net, это похоже на ситуацию, когда может быть несколько счетчиков, которые хранятся локально там, где они используются, и где каким-то образом чтение использования _в _байтах не вызывает немедленную синхронизацию и сводка этих счетчиков.
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.
--https://lwn.net/Articles/258238/
Если у вас небольшая система, -не большое количество процессоров и не поддерживается большое количество контрольных групп -, накладные расходы не кажутся очень значительными. Переброс нескольких строк кэша между процессорами не требует больших затрат. Но эффективность может быть полезной, если вы работаете в Google и используете тысячи контейнеров в системе :)или если у вас есть система с тысячами процессоров.
Я думаю, что вижу несоответствие при просмотре memory.usage _в _байтах, когда процесс выполняется по двум сценариям.
Сценарий 1:Процесс, созданный непосредственно в контрольной группе Показанное использование памяти выглядит правильно.
# cgexec -g memory:mem128 sleep 30 &
[2] 18339
# cat /sys/fs/cgroup/memory/mem128/memory.usage_in_bytes
135168
Сценарий 2:Процесс, созданный отдельно, а затем назначенный контрольной группе. Показано неправильное использование памяти. 36864 кажется неверным. Иногда показывает 0 также. Почему это отличается от сценария 1, показанного выше?
# sleep 90 &
[2] 18937
# cgclassify -g memory:/mem128 18937
# cat /sys/fs/cgroup/memory/mem128/memory.usage_in_bytes
36864