В настоящее время вычисление использования памяти контейнера / группы, возвращаемой в SignalFX, включает кэш страницы Linux.
Как правило, это считается неправильным и может привести к тому, что люди будут преследовать утечки фантомной памяти в своих приложениях.
Чтобы продемонстрировать, почему текущий расчет неверен, вы можете выполнить следующее, чтобы увидеть, как использование ввода-вывода влияет на общее использование памяти в cgroup:
docker run --rm -ti alpine
cat /sys/fs/cgroup/memory/memory.stat
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
dd if=/dev/zero of=/tmp/myfile bs=1M count=100
cat /sys/fs/cgroup/memory/memory.stat
cat /sys/fs/cgroup/memory/memory.usage_in_bytes
Вы должны увидеть, что значение usage_in_bytes увеличивается на 100 МБ только после создания файла размером 100 МБ. Этот файл не был загружен приложением в анонимную память, но, поскольку он теперь находится в кеше страниц, использование памяти контейнера оказывается выше.
Вычтение значения кэша в memory.stat из use_in_bytes показывает, что подлинное использование анонимной памяти не возросло.
Метрика signalFX теперь отличается от того, что вы видите, когда вы запускаете статистику Docker, которая использует вычисления, которые у меня есть здесь.
Кажется, что знание использования кэша страницы для контейнера может быть полезным (хотя я изо всех сил думаю о том, когда), но знание этого как части общего процентного использования cgroup бесполезно, так как тогда оно маскирует ваш реальный RSS использование памяти.
В приложении для сбора мусора с максимальным размером кучи, большим или превышающим предел памяти cgroup (например, параметр -Xmx для java или ядро .NET в режиме сервера), тенденция к проценту будет приближаться к 100 %, а затем просто наведите курсор мыши, предполагая, что среда выполнения может правильно видеть ограничение памяти cgroup.
Если вы используете Smart Agent, я бы порекомендовал использовать монитор docker-container-stats (в который я внесу такую же модификацию, чтобы исключить кеш-память).