Потребление оперативной памяти в языке Go: проблемы и пути решения
Vložit
- čas přidán 17. 06. 2024
- Подписывайтесь на наш канал здесь и в телеграмм 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 - Итоги - Věda a technologie
Какой достойный рассказ!
Спасибо Виталию за знания и выступление, а Evrone - за организацию!
Крутой доклад
Доклад получился замечательный!! И большущее спасибо Витале за референс на мой доклад :)
Отлично, хотелось бы видеть побольше подобных докладов.
Великолепный доклад!
Как хорошо, что я набрел на это видео именно сейчас. Не быть мне senior разрабом)). Хоть и понял почти все.
Спасибо за доклад, хочу дополнить спикера
Если в ваших структурах много разноразмерных полей, следует следить за их порядком
Например, не стоит располагать в структуре поля в порядке bool -> int64 -> bool -> float64, в таком случае, в зависимости от архитектуры процессора, вы можете потерять до 44% памяти только на одной структуре
Если вы используете линтеры, рекомендую настроить "structcheck", он не только находит плохой порядок полей, но и умеет находить самый оптимальный порядок. По итогу, для маленьких объектов с учётом фрагментации, может случиться такое, что вы будете использовать только 25% памяти в проценте от выделенной. Да, 25% -- это худший случай, но 50% -- это вполне реальное значение.
Да, выравнивание данных. Кто программировал до Go на Си или C++ должны быть знакомы с этим
Спасибо! Информативно и без "воды".
доклад огонь
охрененный доклад
нраица
Спасибо большое!
хотел спросить, на 9:00 минуте вы говорили про то, что при получении из слайса указателей более укороченный вариант, через операцию s = s[:1], у нас остается память, которая недоступна для GC.
а для объектов которые хранятся в слайсе по значению но имеют ссылочное поле результат будет таким же?
к примеру вот такие:
type A struct {
Number *int
}
s := []A{........}
s = s[1:]. ??????
Доброго времени суток Виталий. Материал зачётный. а вот звук нет , эхотит немало я не сразу понял почему хочется послушать а ушам неприятно я думаю петличный микрофон решит проблему. ЗЫ. Както и в мой микрофон какашку кинули)
Го комьюнити круто.
А где можно скачать презентацию?
Можно ли как-то получить ссылку либо на презентацию, либо на источники упомянутые в ней? Очень хотелось бы почитить их! Спасибо!
Сам написал - сам отвечу :)
Текст доклада появился на habr - habr.com/ru/amp/post/676960/
czcams.com/video/Ss95RF268T0/video.html Видео доклада источника упомянутый в ней :)
@@Adeonchik большое спасибо. Ютуб по фамилии ищет что-то совершенно не то от вашего однофамильца, но не видит Хайлоад.
Шикарный доклад. Коротко и понятно. Большое спасибо.
Неплохо, но зачем руками махать?