Вопрос или проблема
У меня есть настроенный стек мониторинга процессов с использованием экспортера процессов и Grafana с панелью мониторинга “Профилирование процессов с помощью карты дерева”, и я замечаю некоторые подозрительные явления относительно памяти, которую он сообщает.
Исходя из моего понимания (прочитав эту статью и ссылки, упомянутые в ней):
RSS = Частная память + совместно используемая память
PSS = Частная память + (совместно используемая память / число процессов, использующих эту память)
Это приводит меня к мысли, что RSS >= PSS в любой момент времени.
Вот что я наблюдаю:
- Процесс занимает 39.2 ГБ виртуальной памяти
процессу выделено 39.2 ГБ виртуальной памяти
- Процесс занимает 38.1 ГБ “пропорциональной резидентной памяти”, это имеет смысл
Процесс занимает 38.1 ГБ пропорциональной резидентной памяти
- Здесь это становится подозрительным, процесс занимает только 18.8 ГБ резидентной памяти.
Процесс занимает только 19.2 ГБ резидентной памяти
Правильно ли я понимаю, как работают RSS и PSS? Если да, то какие могут быть причины, по которым этот процесс ведет себя так (или так отчетливо указывается). Я подозревал, что экспортер процессов или Grafana могут быть некорректными, но ни один другой процесс не сообщает о чем-то подозрительном, поэтому я предполагаю, что они работают как ожидалось.
Я посмотрел на GitHub экспортера процессов, чтобы подтвердить, правильно ли я понимаю поля, которые он сообщает.
resident: Поле rss(24) из /proc/[pid]/stat, в котором говорится:
Это просто страницы, которые учитываются для текста, данных или стек-пространства. Это не включает страницы, которые не были загружены по запросу или которые были выгружены.
proportionalResident: Сумма полей "Pss" из /proc/[pid]/smaps, в котором говорится:
"Пропорциональный объем памяти" (PSS) процесса - это количество страниц, которые он имеет в памяти, где каждая страница делится на количество процессов, использующих ее.
Никакие страницы не были выгружены.
Вот запросы, используемые Grafana для построения графиков:
пропорциональная резидентная память:
namedprocess_namegroup_memory_bytes{instance=~"$instance", memtype="proportionalResident"} > 0
виртуальная память:
namedprocess_namegroup_memory_bytes{instance=~"$instance", memtype="virtual"}
резидентная память:
namedprocess_namegroup_memory_bytes{instance=~"$instance", memtype="resident"} / ignoring(memtype) namedprocess_namegroup_num_procs > 0
Все другие процессы ведут себя ожидаемым образом с RSS >= PSS. Почему этот процесс может сообщать такое поведение?
Заранее спасибо!
Ответ или решение
Анализ аномального поведения памяти в процессе мониторинга с использованием Process Exporter и Grafana
В ходе работы с вашим стеком мониторинга, состоящим из Process Exporter и Grafana, вы столкнулись с аномалиями в отчетах по использованию памяти. Это явление требует внимательного анализа, особенно с учетом вашей интерпретации RSS (Resident Set Size) и PSS (Proportional Set Size). Давайте более подробно рассмотрим, что может быть причиной значительного расхождения между этими метриками.
Основные понятия
Для начала, давайте уточним определения:
-
RSS (Resident Set Size): Это количество страниц памяти, занятое процессом, включая как частную, так и общую память. Это означает, что RSS включает все страницы, которые находятся в основной памяти на данный момент.
-
PSS (Proportional Set Size): Это более "умеренное" измерение, которое делит память, которую разделяют несколько процессов, на количество процессов. PSS рассчитывается как сумма частной памяти и доли общей памяти (разделяемой) процесса, деленной на количество активных процессов, использующих эту общую память.
Поправка:
- Вы правы в своем предположении, что в нормальных условиях RSS должен быть больше или равен PSS. Однако ваше наблюдение о том, что RSS составляет 18.8 ГБ, в то время как PSS — 38.1 ГБ, действительно выглядит аномально и требует дальнейшего анализа.
Возможные причины аномального поведения
-
Отсутствие Demand-Page Loading: Ваше утверждение о том, что «никакие страницы не были выгружены», может наводить на мысль о том, что программа может не использовать свою память должным образом, не загружая определенные страницы в физическую память. Это может привести к тому, что основная память (RSS) оказывается меньше, чем предполагается.
-
Состояние памяти и кэширование: В современных системах управления памятью могут возникнуть ситуации, когда процесс использует большое количество виртуальной памяти без фактического использования физических страниц. Это может быть связано с кэшированием или оптимизациями на уровне ОС, при которых память может быть зарезервирована, но фактически не используется.
-
Фрагментация памяти: Если в системе наблюдается высокая степень фрагментации памяти, это может повлиять на объём доступной физической памяти для процессов. Если система не может выделить соответствующий объём памяти из-за фрагментации, это может привести к растущему PSS и уменьшению RSS.
-
Управление памятью на уровне приложения: Некоторые приложения могут использовать "умные" стратегии управления памятью, что приводит к увеличению выделенной памяти без фактического её использования. Если приложение выделяет память, но затем не использует её, это может привести к наблюдаемой аномалии.
Проверка настроек Process Exporter и Grafana
Убедитесь, что ваши настройки Process Exporter корректны. Следует проверить, что все необходимые файлы метрик правильно обрабатываются и отображаются.
-
Проверка вычислений: Перепроверьте SQL-запросы Grafana для правильности. Обратите внимание на корректность использования выброса метриков:
- Процентное соотношение функций (например, деление на количество процессов, как указано в вашем запросе для RSS) может неправильно обрабатываться.
-
Взаимодействие с другими процессами: Проанализируйте, не влияет ли на ваше приложение высокая нагрузка со стороны других процессов, которые могут перераспределять память.
Заключение
Несмотря на то что поведение вашего процесса отображается аномально, оно не обязательно означает, что существует ошибка в вашей системе мониторинга. Проблема может быть связана с самим процессом, его архитектурой или его взаимодействием с ОС. Рекомендуется продолжить наблюдение за поведением этого процесса и провести дополнительные исследования, чтобы понять его использование памяти более детально, возможно, включая такие инструменты, как top, htop, или даже дополнительные метрики из /proc.
Если эти методы ничего не выявят, возможно, имеет смысл обратиться к разработчикам приложения или задать вопрос в специализированных сообществах для более глубокого анализа.