Анализ использования памяти для приложения Go в Linux

Понимание использования памяти в Linux часто бывает нетривиальным, это небольшая попытка выразить это простыми словами и разделить на два простых сценария ниже.

Недавно я работал над этой задачей, чтобы понять, «сколько памяти потребляет наше приложение», и это вызывает множество вопросов, поскольку на нее нет простого ответа из одного слова. Доступен хороший контент, и я опубликую ссылки ниже, вы, скорее всего, встретите такие термины, как VSS, RSS, PSS, USS, общая память, paging и т. д. Смысл этого небольшого письма – попытаться ответить «что вы ищите, учитывая ваши сценарии». Обратите внимание, что приведенное ниже правило анализа / большого пальца предназначено для простого случая, когда не реализовано совместное использование памяти или IPC через общую память.

Сценарий 1. Задайте себе несколько вопросов, например: «Является ли ваше приложение монолитным?», «Выполняется ли ваше приложение как один экземпляр на машину / контейнер / виртуальную машину / хост?». В стеке ваших решений нет уже запущенного или предполагаемого запуска аналогичного приложения. (которые потенциально могут делиться страницами)? Если ответ на все эти вопросы – большое ДА, поищите значение памяти RSS.

Сценарий 2: В противоположных направлениях, если приложение не является монолитным, предполагается, что на компьютере должно выполняться много экземпляров (одного и того же приложения), или по замыслу, рядом с вашим приложением будут другие аналогичные приложения — Если ответ на эти вопросы “ДА”, то рассмотрите значение USS.

Давайте разберемся с терминами

VSS (обозначается как VSZ из ps – Размер виртуальной памяти) ps включает всю память, к которой процесс может получить доступ, включая память, которая выгружается, память, которая выделяется, но не используется, и память из общих библиотек.

RSS (размер резидентного набора) и показывает, сколько оперативной памяти используется во время вывода команды. Также следует отметить, что он показывает весь стек физически выделенной памяти.

PSS (пропорциональный размер набора) процесса – это количество страниц, которые он имеет в памяти, где каждая страница делится на количество процессов, разделяющих ее. (Если P1 и P2 совместно используют X страниц, RSS для P1 и P2 будет X, тогда как PSS для P1 и P2 будет X / 2)

USS (уникальный размер набора), вместо этого, представляет собой простое количество страниц, к которым не предоставлен общий доступ. т.е. количество страниц, которые будут возвращены в систему, если процесс будет остановлен.

Это означает, что когда дело доходит до RSS – RSS не имеет информации о совместном использовании страниц, это может означать, что значение RSS может завышать объем памяти, используемый каждым процессом. Учитывая, что RSS лучше всего подходит для сценария 1 .

С другой стороны, USS – наш лучший выбор, если речь идет о том, «на сколько больше памяти потребуется, если мы запустим еще один идентичный или похожий процесс» с точки зрения библиотек или пакетов, импортируемых процессом.

Давайте посмотрим на цифры ниже, чтобы понять отличия

Запускаем процесс / приложение funapp, наблюдаем RSS и USS. RSS и USS почти одинаковы для первого / единственного экземпляра (сценарий 1, рассмотрим RSS)

Давайте добавим больше экземпляров и обратите внимание на числа, USS будет показывать меньший объем памяти. (Сценарий 2), который указывает «на сколько больше памяти потребуется, если мы запустим еще один процесс» или «количество страниц, которые будут возвращены в систему, если процесс будет остановлен» (Сценарий 2, рассмотрим USS)

Давайте убьем два экземпляра из трех, снова понаблюдаем за значениями USS и RSS. Поскольку нет других экземпляров и нет возможности для совместного использования памяти, USS и RSS возвращаются к исходному диапазону (единичный экземпляр).

Я надеюсь, что это дает некоторую перспективу и помогает кому-то понять поведение памяти и лучше это проанализировать.