Отслеживать утечку памяти в приложении Google App Engine Golang?

Я видел этот вопрос по Python:App Engine Deferred: Отслеживание утечек памяти

... Точно так же я столкнулся с этой страшной ошибкой:

Превышено мягкое ограничение частной памяти в 128 МБ и 128 МБ после обслуживания всего 384 запросов

...

После обработки этого запроса было обнаружено, что процесс, который обработал этот запрос, использует слишком много памяти и был остановлен. Это может привести к использованию нового процесса для следующего запроса к вашему приложению. Если вы часто видите это сообщение, в вашем приложении может быть утечка памяти.

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

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

Поскольку это работает в GAE, я не могу действительно легко профилировать его локально, насколько я знаю, поскольку это среда выполнения.Может ли кто-нибудь иметь предложение относительно того, как действовать и гарантировать, что память перерабатывается должным образом? - Я новичок в Go, но до сих пор мне нравилось с ним работать.

 Ben Guild05 авг. 2016 г., 12:21
Если вы, ребята, хотите представить их в качестве ответов ниже, я буду голосовать за них обоих. Спасибо!
 twotwotwo05 авг. 2016 г., 06:34
A профиль кучи (описано по этой ссылке вместе с распределением и профилями ЦП) может рассказать вам, что использует большую часть ОЗУ.runtime/pprof можете отправить кучу проф. любомуWriter в том числеhttp.ResponseWriter; Вы могли бы запустить это за какой-то аутентификации в производстве.
 Ben Guild05 авг. 2016 г., 12:20
@DanCornilescu Я мог бы попробовать это, спасибо за рекомендацию. Я действительно думаю, что, возможно, нашел утечку, работая над идеей twotwotwo выше, но я посмотрю, останется ли она.
 Ben Guild05 авг. 2016 г., 12:20
@twotwotwo Теперь у меня есть запись, спасибо за идею.
 Dan Cornilescu05 авг. 2016 г., 06:49
Вы можете посмотреть на это по-другому: временно обновиться до следующего (1 или 2) экземпляра класса (ов) и проверить тенденцию использования памяти. Если он стабилизируется через некоторое время, то класс экземпляра был действительно слишком мал - готово :) Если он продолжает расти (в конечном итоге вызывает перезапуск экземпляра), тогда действительно происходит некоторая утечка памяти, и расследованиеможет быть быть необходимым (скорость перезапуска экземпляраможет быть быть терпимым с более высоким классом экземпляра). Такие перезапуски можно рассматривать как «функцию» периодического обновления / самоочищения, позволяющую, например, сосредоточиться на других, более насущных вопросах;)

Ответы на вопрос(2)

Решение Вопроса

pprof.WriteHeapProfile, Это напишет любойWriterв том числеhttp.ResponseWriter, таким образом, вы можете написать представление, которое проверяет некоторую аутентификацию и дает вам профиль кучи. Раздражает то, что это действительно отслеживаниеассигнования, не то, чтоостатки выделено после ГХ. Так что, в некотором смысле, он говорит вам, что требует много памяти, но не предназначается специально для утечек.

Стандартexpvar Пакет может предоставлять некоторые JSON, включая memstats, который сообщает вам о GC и количествеи освобождает определенных размеров размещения (пример). Если есть утечка, вы можете использоватьallocs-frees чтобы понять, большие ли это ресурсы или маленькие, которые растут со временем, но это не очень детально.

Наконец, естьфункция для сброса текущего состояния кучи, но я не уверен, что он работает в GAE и, похоже, используется редко.

Обратите внимание, что для поддержания работы GC процессы Go увеличиваются примерно вдвое по сравнению с их действительными данными.как часть нормальной стационарной работы, (Точный% он растет до GC зависит отruntime.GOGC, которые люди иногда увеличивают, чтобы сохранить работу коллектора в обмен на использование большего количества памяти.) (Очень старая) ветка предлагаетПроцессы App Engine регулируют сборщик мусора, как и любой другойхотя они могли бы подправить его с 2011 года. Во всяком случае, если вы распределяете медленно (хорошо для вас!), вы должныожидать медленный рост процесса; просто использование должно возвращаться снова после каждого цикла сбора.

чтобы проверить, действительно ли ваше приложение имеет утечку памяти, состоит в том, чтобы временно обновить класс экземпляра и проверить схему использования памяти (в консоли разработчика наInstances выберите страницуMemory Usage для соответствующей версии модуля).

Если шаблон в конечном итоге выравнивается, и экземпляр больше не перезапускается, значит, класс вашего экземпляра слишком низок. Готово :)

Если шаблон использования продолжает расти (со скоростью, пропорциональной активности приложения), то действительно у вас есть утечка памяти. Во время этого упражнения выможет быть иметь возможность также сузить область поиска - если вам удастся сопоставить области роста графика с определенными действиями приложения.

Даже если есть утечка, использование более высокого класса экземпляра должно увеличить время между перезапусками экземпляра, возможно, даже сделать ихтерпимый (сопоставимо, например, с автоматическим отключением динамически управляемых экземпляров). Что позволило бы отложить расследование утечки памяти на задний план и сосредоточиться на более насущных вопросах, если это вас интересует. Можно рассматривать такие перезапуски как «функцию» обновления / самоочищения экземпляра :)

Ваш ответ на вопрос