Управление памятью и сборщиком мусора в Go

22 мая Нина сделала новый доклад на Go-митапе в Москве: kzbin.info5BTrGM5ElAA
Слайды: prog.msk.ru/downloads/go-garb...
Репозиторий: github.com/PakshNina/gc
Разработчики языка Go утверждают, что можно не задумываться о том, как работает сборщик мусора. Но бывают ситуации, когда понимание внутренних механизмов очистки динамической памяти может помочь оптимизировать ваше приложение и избежать многих проблем.
13 июля в своем докладе Нина Пакшина расскажет, на что можно рассчитывать от сборщика мусора, как им можно управлять и как мягкое управление памятью помогает избежать ошибки Out-Of-Memory.
В докладе будут освещены полезные инструменты для анализа динамической памяти, а также будет рассказано, как можно вручную аллоцировать память с помощью новой экспериментальной фичи Arena из свежей версии Go.
В организации нам помогает наш партнёр SBTG.RU(sbtg.ru/). Трансляции в любых конфигурациях под ключ.
Чтобы быть в курсе IT-событий, подпишитесь на телеграм-канал ITMeeting(itmeeting.ru/). Это наши друзья, которые анонсируют бесплатные мероприятия в Москве и Онлайне. Здесь вы найдёте и конференции, и митапы, и семинары - форматы на любой вкус. Канал анонсирует и наши встречи. Подписывайтесь.

[@PetrPichugin]

Ну вот когда классно, тогда классно! Браво, Нина!! 👏 Получил огромное удовольствие и пользу от просмотра!

[@user-fj1ym4fk6s]

Отличный доклад на простом языке!!!

[@user-jw6bn4ic4x]

Большое спасибо за интересный и полезный доклад!

[@user-qp3lt4ps8c]

Очень интересный доклад. Спасибо, Нина!

[@Mumongi]

Крутой доклад, разжевано максимально доходчиво. ❤

[@ivangurin7062]

Нина, спасибо за доклад!

[@ninucium]

Спасибо за обратную связь)

[@defer99]

Отличный доклад, спасибо

[@ninucium]

Спасибо!

[@user-ie3du3dj7u]

Спасибо!

[@akaassa73]

Это жирный плюс в карму. Но ссылку на репку я так и не нашёл.

[@progmsk]

Извините, забегались. Добавили ссылку в описание.

[@batpyiiikob7245]

спасибо - мой случай. Очень помогли. частенько контейнер отваливался аутофмемори :)

[@pavelerokhin1512]

спасибо!

[@user-sh4kl2hr1f]

лучшая

[@yarbersheer8559]

у меня только один вопрос: как линтер пропустил комментарии без точки в конце?)) Спасибо за доклад и ссылки.

[@ninucium]

Кошмар, безобразие. Он просто был не настроен)

[@mikhailmusofranov3943]

Спасибо большое. Но "утечка данных" у Яндекса бывает. А тут речь об утечке памяти.

[@ninucium]

Спасибо за замечание, оговорилась)

[@Trickster2208]

А как gc в первый раз вызывается? Изначально живая куча же 0 или я не прав?

[@alexanderkozlikhin]

Хороший доклад, дающий толчок к более глубокому самостоятельному изучению всех аспектов управления памятью в Go. Прекрасная докладчица! Одно все время напрягало - выступавшая с докладом девушка как будто дико стеснялась использовать грамотный литературный русский язык, не могла позволить себе говорить без речевых ошибок почти в каждом предложении. Может быть, это такая стилистика теперь, и это воспринимается как что-то официально-умное и вместе с тем неформально-ненапряжное в речи? Много у кого это вижу :)

[@anar-k-jafarov]

08:25 ошибка 1 280 185 040 ns = 1.2 s а не 1 миллисекунда как бы много мусора = много времени на маркировку и удаление поправьте если не прав

[@yarbersheer8559]

всё верно. Нано - 10^-9 => 1,2s

[@yarbersheer8559]

Единственное, это поле Старт т.е. временная метка запуска GC от начала исполнения программы.) А время работы GC Wall Duration = 721,248nm => 721 микроСекунда) в первом примере по просмотру времени работы общее время работы GC составило 8.5 milis т.к. было частое срабатывание. Каждое срабатывание требовано 225 micros. Вот и накопилось. Т.е. явно показано, что большой буфер GC увеличивает нагрузку на память, но уменьшает процессорное время. В первом случае 20МБ и 8мс, во втором 1000МБ и 721микрос

[@yarbersheer8559]

Маркировка не входит во время работы GC, на сколько мне помнится. Она не вызывает Stop The World.

[@user-pt7nv3jb5j]

кроме стека и кучи есть еще кэш процессора

[@vova_dev]

В каком контексте его можно здесь использовать?