Потребление оперативной памяти в языке Go: проблемы и пути решения

Рет қаралды 13,534

Күн бұрын

Подписывайтесь на наш канал здесь и в телеграмм t.me/meetups_evrone, чтобы быть в курсе будущих митапов и не пропускать полезные доклады!
Виталий Исаев - МойОфис
Рантайм языка Go содержит множество оптимизаций, увеличивающих эффективность работы с оперативной памятью, но ничего не знает об ограничениях, которые могут быть установлены для процесса операционной системой. Поэтому за каждой программой, написанной на Go, рано или поздно придёт OOM killer. Мы поговорим о возможностях, заложенных для решения этой проблемы авторами языка, и о том, чем ответило сообщество, проанализируем опыт крупных open-source проектов и сопоставим Go с другими современными языками программирования.
#go #golang #meetup #evrone
00:00 - Введение
00:55 - Почему Go - хороший язык
01:16 - GitHub Go issues
02:19 - Так ли страшны утечки памяти в Go?
02:39 - Что делает ОС при исчерпании памяти
03:55 - Последствия аварийной остановки
04:15 - Сброс кешей
04:49 - Каскадные сбои
05:24 - Распределенные транзакции
06:38 - Мониторинг потребление памяти в Go
07:30 - Причины высокого потребления памяти в Go
07:54 - Ошибки бизнес-логики
13:47 - Управление памятью в Go
14:12 - Как организована работа с оперативной памятью в современных ОС
15:22 - Проблема фрагментации памяти
19:10 - Сборка мусора в Go
20:06 - GC Pacer
21:45 - Лимиты потребления памяти в Go
22:16 - Действия при приближению к лимиту памяти в Go
23:38 - Проект MemLimiter
25:27 - Трудный путь SetMemoryLimit
26:59 - Scavenger
29:20 - Итоги

Пікірлер: 22

@mikhailrumpel 2 жыл бұрын

Какой достойный рассказ! Спасибо Виталию за знания и выступление, а Evrone - за организацию!

@vsurkov 2 жыл бұрын

Крутой доклад

@Adeonchik Жыл бұрын

Доклад получился замечательный!! И большущее спасибо Витале за референс на мой доклад :)

@user-jg9bm6ft3q Ай бұрын

Великолепный доклад!

@user-sz8gx6bb5t 4 ай бұрын

Отлично, хотелось бы видеть побольше подобных докладов.

@raneddo Жыл бұрын

Спасибо за доклад, хочу дополнить спикера Если в ваших структурах много разноразмерных полей, следует следить за их порядком Например, не стоит располагать в структуре поля в порядке bool -> int64 -> bool -> float64, в таком случае, в зависимости от архитектуры процессора, вы можете потерять до 44% памяти только на одной структуре Если вы используете линтеры, рекомендую настроить "structcheck", он не только находит плохой порядок полей, но и умеет находить самый оптимальный порядок. По итогу, для маленьких объектов с учётом фрагментации, может случиться такое, что вы будете использовать только 25% памяти в проценте от выделенной. Да, 25% -- это худший случай, но 50% -- это вполне реальное значение.

@andrew_chumakov 9 ай бұрын

Да, выравнивание данных. Кто программировал до Go на Си или C++ должны быть знакомы с этим

@research_Development Жыл бұрын

Как хорошо, что я набрел на это видео именно сейчас. Не быть мне senior разрабом)). Хоть и понял почти все.

@brothers_karamazovs Жыл бұрын

Спасибо! Информативно и без "воды".

@user-by2qo9zy5k 8 ай бұрын

доклад огонь

@alexandersmirnov4274 Жыл бұрын

охрененный доклад

@ayaz.ayupov Жыл бұрын

Спасибо большое! хотел спросить, на 9:00 минуте вы говорили про то, что при получении из слайса указателей более укороченный вариант, через операцию s = s[:1], у нас остается память, которая недоступна для GC. а для объектов которые хранятся в слайсе по значению но имеют ссылочное поле результат будет таким же? к примеру вот такие: type A struct { Number *int } s := []A{........} s = s[1:]. ??????

@fellainthewagon7166 Жыл бұрын

нраица

@ruslibertarian Жыл бұрын

Го комьюнити круто.

@coolcatbaby 2 жыл бұрын

А где можно скачать презентацию?

@realtimeuser Жыл бұрын

Доброго времени суток Виталий. Материал зачётный. а вот звук нет , эхотит немало я не сразу понял почему хочется послушать а ушам неприятно я думаю петличный микрофон решит проблему. ЗЫ. Както и в мой микрофон какашку кинули)