�ݺ�ߣ

Управление памятью в GO

План вебинара:
1. Адресное пространство процесса в Linux. Основы управления памятью в
современных ОС.
2. Управление памятью в GO.
3. Оптимизация GO программ. Toolchain и примеры. Cgo.

Адресное пространство процесса в Linux

Адресное пространство процесса в Linux. Stack
- LIFO структура данных.
- Ограничен ОС.
- Элемент данных - stack frame.
Представляет собой память под
локальные переменные, аргументы
и возвращаемые значения функции.
- Размер stack frame'а известен на
этапе компиляции, количество - нет.
- Память очищается автоматически.

Адресное пространство процесса в Linux. Heap
- произвольный доступ
- ОС не ограничивает размер
- размер не известен на этапе компиляции, нужно запрашивать память у ОС
- нет автоматической очистки

Адресное пространство процесса в Linux. Heap
Запросить память в linux
можно:
1. brk (sbrk)
2. mmap

Адресное пространство процесса в Linux.
Stack VS Heap
Stack Heap
Есть ограничения по максимальному размеру Нет ограничений по максимальному размеру
Статичен, размер stack frame'а известен на этапе
компиляции
Хранение данных размер которых не известен на
этапе компиляции
Функция "видит" память только своего stack frame Произвольный доступ (из разных функций, потоков
и даже процессов)
Автоматический менеджмент памяти Нужно подчищать (или переиспользовать) память:
- ручное управление (malloc/free)
- полуавтоматическое управление (unique_ptr,
shared_ptr)
- автоматическое управление (garbage collection)

На практике куча нужна если:
- функция хочет видеть данные аллоцированные в другой функции
- имеем дело с данными динамического размера
- имеем дело с данными большого размера
- данные "шарятся" между потоками
Адресное пространство процесса в Linux.
Stack VS Heap

Управление памятью в GO. Аллокатор
Используется свой аллокатор tcmalloc:
- mmap (not brk)
- память под stack горутины на самом деле выделяется в heap
- используется garbage collector

Управление памятью в GO. Heap тормозит?
Нет! Тормозит gc:
- должен знать о всей памяти выделяемой на heap'е, выполнять обход этой
памяти
- полностью останавливать программу для очистки памяти (STW)
- сохранять инвариант
- бороться с фрагментацией

Управление памятью в GO. А можно ли управлять?
int *mul2(int x) {
int multiplier = 2; // allocated
on stack
int *result =
malloc(sizeof(int)); // allocated on heap
*result = x * multiplier;
return result;
}
func mul2(x int32) *int32 {
var multiplier int32 = 2 //
allocated on stack
result := x * multiplier //
allocated on heap
return &result
}

Управление памятью в GO. А можно ли управлять?
В GO компилятор сам решает где аллоцировать переменную, он действует
согласно набору эвристик - escape analysis. Используя эти правила можно
заставить компилятор GO аллоцировать память там где нам надо.

Оптимизация. Toolchain
Кун-фу оптимизации:
- локализовать "горячее" место - pprof
- обеспечить повторяемость, тестируемость гипотез - go benchmark
- провести анализ кода - escape analysis
- ?????
- PROFIT!
"Преждевременная оптимизация — корень всех зол" - Дональд Кнут.

Оптимизация. Toolchain. Pprof
Можно профилировать тесты либо добавить к себе pprof сервер.
Профилирование по памяти - показывает где и сколько аллоцируется памяти
в heap'е. Профилирование производительности может подтвердить что
аллокации замедляют нашу программу.

Оптимизация. Toolchain. GO benchmark
Позволяют обеспечить повторяемость сценария который мы хотим
оптимизировать. Показывает сколько процессорного времени и аллокаций
было затрачено на одну итерацию бенчмарка.
```bash
go test . -bench=. -benchmem
```

Оптимизация. Toolchain. Escape Analysis
Объясняет почему компилятор GO аллоцировал память так а не иначе.
```bash
go test . -gcflags="-m -m"
```

Оптимизация. Примеры. Копирование структуры
type S struct {
a, b, c int64
d, e, f string
g, h, i float64
}
func byPointer() *S {
return &S{
a: 1, b:
1, c: 1,
e: "foo",
f: "foo",
g: 1.0,
h: 1.0, i: 1.0,
}
}
BenchmarkMemoryHeap
41.43 ns/op 96 B/op 1 allocs/op
func BenchmarkMemoryHeap(b *testing.B) {
var s *S
for i := 0; i < b.N; i++ {
s =
byPointer()
}
_ = fmt.Sprintf("%v", s.a)
}
func byCopy() S {
return S{
a: 1, b: 1,
c: 1,
e: "foo",
f: "foo",
g: 1.0, h:
1.0, i: 1.0,
}
}
func BenchmarkMemoryStack(b *testing.B) {
var s S
for i := 0; i < b.N; i++ {
s = byCopy()
}
_ = fmt.Sprintf("%v", s.a)
}
BenchmarkMemoryStack
func BenchmarkMemoryHeap2(b *testing.B) {
for i := 0; i < b.N; i++ {
s :=
byPointer()
if s.a != 1 {
panic("a!=1")
}
}
}
BenchmarkMemoryHeap2-4

Оптимизация. Примеры. Строки
type PackageType string
const (
TypeControl = "control"
TypeData = "data"
TypeUnknown = "unknown"
)
type RawPackage struct {
typ []byte
}
func ParseType(p *RawPackage) PackageType {
strType := string(p.typ)
switch strType {
case TypeControl, TypeData:
return
PackageType(strType)
default:
return
TypeUnknown
}
}
func BenchmarkParse(b *testing.B) {
for i := 0; i < b.N; i++ {
typ :=
ParseType(testPackages[i % 3])
runtime.KeepAlive(typ)
}
}
BenchmarkParse
16.44 ns/op 5 B/op
1 allocs/op
var (
TypeControlBytes = []byte("control")
TypeDataBytes = []byte("data")
)
func ParseTypeNoAlloc(p *RawPackage) PackageType {
if bytes.Compare(p.typ, TypeControlBytes)
== 0 {
return TypeControl
}
if bytes.Compare(p.typ, TypeDataBytes) == 0
{
return TypeData
}
return TypeUnknown
}
func BenchmarkParseNoAlloc(b *testing.B) {
for i := 0; i < b.N; i++ {
tp :=
ParseTypeNoAlloc(testPackages[i % 3])
runtime.KeepAlive(tp)
BenchmarkParseNoAlloc
8.699 ns/op 0 B/op
0 allocs/op

Оптимизация. Примеры. Строки
func ExternalLibFunc(typ string) {
}
func BenchmarkExternal(b *testing.B) {
var str string
for i := 0; i < b.N; i++ {
str =
string(testPackages[i % 3].typ)
ExternalLibFunc(str)
}
}
BenchmarkExternal
func (p *RawPackage) TypeUnsafe() string {
return
*(*string)(unsafe.Pointer(&p.typ))
}
func BenchmarkExternalNoAlloc(b *testing.B) {
var str string
for i := 0; i < b.N; i++ {
str = testPackages[i %
3].TypeUnsafe()
ExternalLibFunc(str)
}
}
BenchmarkExternalNoAlloc

Оптимизация. Примеры. Контейнеры
func ManualBenchmark(f func(), benchName string) {
iterCnt := 10_000
startMs := &runtime.MemStats{}
runtime.ReadMemStats(startMs)
startTime := time.Now().UnixNano()
for i := 0; i < iterCnt; i++ {
f()
}
endTime := time.Now().UnixNano()
endMs := &runtime.MemStats{}
runtime.ReadMemStats(endMs)
fmt.Printf(
"%s %d ns/op %d b/op %d
allocs/op n",
benchName,
(endTime-startTime)/int64(iterCnt),
(endMs.HeapAlloc-
startMs.HeapAlloc)/uint64(iterCnt),
(endMs.Mallocs-
startMs.Mallocs)/uint64(iterCnt),
)
}

type Storage struct {
data []interface{}
}
func (s *Storage) Add(el int) {
s.data = append(s.data, el)
}
var nums = []int{3, 2, 20, 5}
ManualBenchmark(func() {
intStorage :=
&Storage{}
for _, v := range
nums {
intStorage.Add(v)
}
}, "DefaultStorageBenchmark")
DefaultStorageBenchmark
208 ns/op 112 b/op 3 allocs/op
type IntStorage struct {
data []int
}
func (s *IntStorage) Add(el int) {
s.data = append(s.data, el)
}
intStorage :=
&IntStorage{}
for _, v := range nums {
intStorage.Add(v)
}
}, "IntStorageBenchmark")
IntStorageBenchmark

int = int64 (для 64битой машины)
SizeOf(int) = 64 (bit) = 8 (byte)
interface{}
type emptyInterface struct {
typ *rtype
word unsafe.Pointer
}
SizeOf(interface{}) = 128 (bit) = 16 (byte)
go run -gcflags=-G=3 main.go

type genericStorage[T comparable] struct
{
data []T
}
func (s *genericStorage[T]) Add(el T) {
s.data = append(s.data,
el)
}
intStorage :=
&genericStorage[int]{}
for _, v := range nums {
intStorage.Add(v)
}
}, "GenericStorageBenchmark")
DefaultStorageBenchmark
IntStorageBenchmark
GenericStorageBenchmark

Оптимизация. Бонус
А что если Cgo? Как быть с утечками?
Ответ: еще одна тулза - Valgrind!

�ݺ�ߣ

Управление памятью в GO

Recommended

More Related Content

What's hot (20)

Similar to Управление памятью в GO (20)

Управление памятью в GO