Я написав програму golang, яка використовує 1,2 Гб пам'яті під час виконання.
go tool pprof http://10.10.58.118:8601/debug/pprof/heapРезультатом виклику є дамп із використанням лише купи 323,4 МБ.
Використовуючи gcvisя отримую це:
.. і цей профіль форми купи:
Ось мій код: https://github.com/sharewind/push-server/blob/v3/broker
Відповіді:
Профіль купи показує активну пам’ять, пам’ять, яку виконує програма, використовується програмою go (тобто: не зібрана збирачем сміття). Коли GC збирає пам'ять, профіль стискається, але пам'ять в систему не повертається . Ваші майбутні розподіли намагатимуться використовувати пам’ять із пулу раніше зібраних об’єктів, перш ніж запитувати у системи більше.
Зовні це означає, що використання пам'яті вашої програми буде або збільшуватися, або залишатись на рівні. Те, що зовнішня система представляє як "постійний розмір" вашої програми, - це кількість байтів оперативної пам'яті, призначеної вашій програмі, незалежно від того, чи містять вона значення використання go або зібрані.
Причина, чому ці два числа часто досить різні, полягає в тому, що:
Якщо ви хочете отримати точну інформацію про те, як Go бачить пам'ять, ви можете використовувати час виконання. ВикликReadMemStats: http://golang.org/pkg/runtime/#ReadMemStats
Крім того, оскільки ви використовуєте веб-профілювання, якщо ви можете отримати доступ до даних профілювання через ваш браузер за адресою:, http://10.10.58.118:8601/debug/pprof/клацнувши посилання купи, ви побачите налагоджувальний вигляд профілю купи, який має роздруковану структуру середовища виконання. знизу.
Документація runtime.MemStats ( http://golang.org/pkg/runtime/#MemStats ) містить пояснення всіх полів, але цікавими для цього обговорення є:
Все ще існуватимуть розбіжності між системою Sys, і те, про що повідомляє ОС, оскільки те, що Go просить про систему, і те, що ОС дає їй, не завжди однакові. Також пам'ять CGO / syscall (наприклад: malloc / mmap) не відстежується за допомогою go.
/debug/pprof/heapне містить роздруківки середовища виконання. Struktura MemStats
Allocі HeapAllocмає таке ж значення.
Як доповнення до відповіді @Cookie of Nine, коротко: ви можете спробувати цей --alloc_spaceваріант.
go tool pprofвикористовувати --inuse_spaceза замовчуванням. Він вибірково використовує пам’ять, тому результат є підмножиною реального.
За допомогою --alloc_spacepprof повертає всю виділену пам'ять з моменту запуску програми.
--alloc_spaceсаме те, що я шукав.
Мене завжди бентежило зростаюча житлова пам’ять моїх програм Go, і нарешті мені довелося вивчити інструменти профілювання, які є в екосистемі Go. Runtime надає багато метрик у структурі Runtime.Memstats , але може бути важко зрозуміти, який з них може допомогти з'ясувати причини зростання пам'яті, тому потрібні деякі додаткові інструменти.
Середовище профілювання
Використовуйте https://github.com/tevjef/go-runtime-metrics у своєму додатку. Наприклад, ви можете помістити це у свій main:
import(
metrics "github.com/tevjef/go-runtime-metrics"
)
func main() {
//...
metrics.DefaultConfig.CollectionInterval = time.Second
if err := metrics.RunCollector(metrics.DefaultConfig); err != nil {
// handle error
}
}
Запуск InfluxDBі Grafanaв Dockerконтейнерах:
docker run --name influxdb -d -p 8086:8086 influxdb
docker run -d -p 9090:3000/tcp --link influxdb --name=grafana grafana/grafana:4.1.0
Налаштуйте взаємодію між Grafanaі InfluxDB Grafana(Головна сторінка Grafana -> Лівий верхній кут -> Джерела даних -> Додати нове джерело даних):
Імпортуйте інформаційну панель № 3242 з https://grafana.com (головна сторінка Grafana -> Лівий верхній кут -> Інформаційна панель -> Імпорт):
Нарешті, запустіть свою програму: вона передаватиме метрики виконання конненерованому Influxdb. Покладіть свою програму на розумне навантаження (у моєму випадку це було досить мало - 5 RPS на кілька годин).
Аналіз споживання пам'яті
Sys(синонім RSS) кривої досить схожий на HeapSysкриву. Виявляється, динамічне розподіл пам’яті було головним фактором загального зростання пам’яті, тому малий обсяг пам’яті, що споживається змінними стека, здається постійним і його можна ігнорувати;HeapIdleзростає з тими самими темпами, що і Sys, а HeapReleasedзавжди дорівнює нулю. Очевидно , під час виконання не повертає пам'ять операційної системи на всіх , по крайней мере , в умовах даного тесту:HeapIdle minus HeapReleased estimates the amount of memory that could be returned to the OS, but is being retained by the runtime so it can grow the heap without requesting more memory from the OS.
Тим, хто намагається дослідити проблему споживання пам'яті, я рекомендую дотримуватися описаних кроків, щоб виключити деякі тривіальні помилки (наприклад, витік програми).
Явне звільнення пам’яті
Цікаво, що можна значно зменшити споживання пам'яті за допомогою явних викликів debug.FreeOSMemory():
// in the top-level package
func init() {
go func() {
t := time.Tick(time.Second)
for {
<-t
debug.FreeOSMemory()
}
}()
}
Насправді такий підхід заощадив близько 35% пам'яті порівняно із умовами за замовчуванням.
Ви також можете використовувати StackImpact , який автоматично реєструє та повідомляє на інформаційну панель регулярні та викликані аномалією профілі розподілу пам'яті, які доступні в історичній та порівнянній формі. Докладнішу інформацію про виявлення витоків пам'яті у додатках Production Go див. У цьому щоденнику
Застереження: я працюю на StackImpact
--alloc_space, що не підходить для виявлення витоків пам'яті. Він просто покаже вам, скільки пам'яті було виділено з моменту запуску програми. Для довготривалої програми цифри можуть стати досить високими. На сьогодні нам не відомо про витоки пам'яті в агенті StackImpact.