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

Рет қаралды 14,160

Күн бұрын

Подписывайтесь на наш канал здесь и в телеграмм 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 - Итоги

Пікірлер: 23

@vsurkov 2 жыл бұрын

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

@Adeonchik Жыл бұрын

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

@mikhailrumpel 2 жыл бұрын

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

@user-jg9bm6ft3q 3 ай бұрын

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

@raneddo Жыл бұрын

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

@andrew_chumakov 10 ай бұрын

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

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

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

@research_Development Жыл бұрын

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

@brothers_karamazovs Жыл бұрын

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

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

доклад огонь

@alexandersmirnov4274 Жыл бұрын

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

@gewalt5886 Ай бұрын

доклад хороший но микрофон бы настроить чтобы все вдохи не слышать

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

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

@ruslibertarian Жыл бұрын

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

@realtimeuser Жыл бұрын

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