У меня есть несколько виртуальных машин в Windows Azure, на которых работает наш веб-сайт электронной коммерции, и в последнее время мы начали использовать Telegraf, InfluxDb и Grafana, чтобы следить за этими машинами. После пары недель сбора данных я заметил странную закономерность, связанную с метрикой доступной памяти :
Каждый день, почти всегда в один и тот же период дня, я замечал, что высвобождается внезапное количество памяти, которое из-за моих очень очень очень ограниченных навыков DevOp я не могу понять, что является причиной этого.
Вот диаграмма, которая показывает этот шаблон:
Мой вопрос: что может привести к чему-то подобному? У меня возникает соблазн подозревать, что виновата утечка памяти, но ... Свободная память никогда не опускается ниже 70%, а происходит только на двух виртуальных машинах с наибольшим трафиком!
Должен ли я быть обеспокоен, когда я вижу что-то подобное?
PS: я просмотрел сбор метрик для частных и виртуальных байтов для каждой из запущенных нами служб Windows и для процесса w3wp ... хотя я читал, что эти метрики не очень надежны, чтобы выяснить, есть ли у вас утечка памяти, но, по крайней мере, я постараюсь получить какую-то тенденцию и посмотреть, соответствует ли она шаблону, показанному выше.
Ответы:
Я видел такой же паттерн «пилообразная» в других системах, в частности, в инструменте данных на основе Java. Исходя из вашего описания, я думаю, что вы смотрите на сборку мусора .NET (если предположить, что это приложение .NET). Java и .NET являются языками с управляемой памятью и средами, которые используют сборщик мусора.
Утечка памяти обычно находится в рамках , которые испытывают недостаток управления памятью, или в программе по рамкам памяти управляемого что переопределяете или запутанным сборщик мусора.
Тот факт, что это ваши серверы с наибольшим трафиком, имеет смысл. Вы видите, что .NET Framework выделяет память по мере необходимости, затем сборщик мусора запускается на регулярной основе и восстанавливает неиспользуемую память, используя алгоритмы сборки мусора. Если вы не отслеживаете конкретные проблемы с производительностью, я не думаю, что такая схема использования памяти является проблемой.
источник
Я думаю, что выяснили, почему этот график выглядит так.
Я также собираю метрики для счетчика общей производительности приложений и ошибок ASP.NET, и я заметил, что точно в то же самое время, когда происходит всплеск доступной памяти, метрика суммарных ошибок сбрасывается до 0.
Согласно msdn этот счетчик сбрасывается в 0 каждый раз, когда происходит перезапуск / завершение работы приложения.
Это заставляет меня поверить, что причина этого пилообразного паттерна «Доступная память» связана с перезапуском приложения.
Вот как выглядят мои графики:
ОБНОВИТЬ
Это происходит из-за того, что количество приватных байтов процесса W3WP достигло предела для рециркуляции (в пуле приложений настроено ограничение количества приватных байтов). И если присмотреться к таблице Private Bytes, мы увидим, что происходит что-то ненормальное, потому что использование памяти увеличивается с 650 МБ до 3,2 ГБ, а спустя несколько часов - с 3,6 ГБ до 16,6 ГБ! Это когда происходит переработка.
источник