Управление потреблением памяти

Я новичок в Go и пытаюсь понять, как он управляет потреблением памяти.

У меня проблемы с памятью в одном из моих тестовых проектов. Я не понимаю, почему Go использует все больше и больше памяти (никогда не освобождая ее), когда моя программа работает в течение длительного времени.

Я запускаю тестовый пример, приведенный ниже. После первого выделения программа использует около 350 МБ памяти (в соответствии с ActivityMonitor). Затем я пытаюсь освободить его, а ActivityMonitor показывает, что потребление памяти удваивается. Зачем?

Я запускаю этот код в OS X, используя Go 1.0.3.

Что не так с этим кодом? И каков правильный способ управления большими переменными в программах Go?

У меня была другая проблема с управлением памятью при реализации алгоритма, который использует много времени и памяти; после запуска в течение некоторого времени он выдает исключение «из памяти».

package main

import ("fmt" 
"time"
)

func main() {
  fmt.Println("getting memory")
  tmp := make([]uint32, 100000000)
  for kk, _ := range tmp {
    tmp[kk] = 0
  }
  time.Sleep(5 * time.Second)
  fmt.Println("returning memory")
  tmp = make([]uint32, 1)
  tmp = nil
  time.Sleep(5 * time.Second)
  fmt.Println("getting memory")
  tmp = make([]uint32, 100000000)
  for kk, _ := range tmp {
    tmp[kk] = 0
  }
  time.Sleep(5 * time.Second)
  fmt.Println("returning memory")
  tmp = make([]uint32, 1)
  tmp = nil
  time.Sleep(5 * time.Second)  
  return
}
25
nl ja de
«Я запускаю этот код на OSx, go1.0.3». Если вам необходимо сделать что-то интенсивное использование памяти с помощью подсказки Go (что станет 1.1), настоятельно рекомендуется. Сначала я был осторожен, но после того, как несколько разработчиков Go рекомендовали его, он был более стабильным, чем 1.0.3 для меня, особенно. в отношении использования памяти.
добавлено автор voidlogic, источник
Вот ссылка на хорошую статью об управлении памятью в Go: lwn.net/Articles/428100
добавлено автор OlliP, источник

2 ответы

В настоящее время go использует mark-and-sweep сборщик мусора , который вообще не определяет, когда объект выброшен.

Однако, если вы посмотрите внимательно, существует подпрограмма go, называемая sysmon , который по существу работает до тех пор, пока ваша программа выполняет и периодически вызывает GC:

// forcegcperiod is the maximum time in nanoseconds between garbage
// collections. If we go this long without a garbage collection, one
// is forced to run.
//
// This is a variable for testing purposes. It normally doesn't change.
var forcegcperiod int64 = 2 * 60 * 1e9

(...)

// If a heap span goes unused for 5 minutes after a garbage collection,
// we hand it back to the operating system.
scavengelimit := int64(5 * 60 * 1e9)

forcegcperiod determines the period after which the GC is called by force. scavengelimit determines when spans are returned to the operating system. Spans are a number of memory pages which can hold several objects. They're kept for scavengelimit time and are freed if no object is on them and scavengelimit is exceeded.

Далее в коде вы видите, что есть опция трассировки. Вы можете использовать это, чтобы видеть, всякий раз, когда мусорщик считает, что ему нужно очистить:

$ GOGCTRACE=1 go run gc.go
gc1(1): 0+0+0 ms 0 -> 0 MB 423 -> 350 (424-74) objects 0 handoff
gc2(1): 0+0+0 ms 1 -> 0 MB 2664 -> 1437 (2880-1443) objects 0 handoff
gc3(1): 0+0+0 ms 1 -> 0 MB 4117 -> 2213 (5712-3499) objects 0 handoff
gc4(1): 0+0+0 ms 2 -> 1 MB 3128 -> 2257 (6761-4504) objects 0 handoff
gc5(1): 0+0+0 ms 2 -> 0 MB 8892 -> 2531 (13734-11203) objects 0 handoff
gc6(1): 0+0+0 ms 1 -> 1 MB 8715 -> 2689 (20173-17484) objects 0 handoff
gc7(1): 0+0+0 ms 2 -> 1 MB 5231 -> 2406 (22878-20472) objects 0 handoff
gc1(1): 0+0+0 ms 0 -> 0 MB 172 -> 137 (173-36) objects 0 handoff
getting memory
gc2(1): 0+0+0 ms 381 -> 381 MB 203 -> 202 (248-46) objects 0 handoff
returning memory
getting memory
returning memory

Как вы можете видеть, gc invoke не делается между получением и возвратом. Однако, если вы измените задержка от 5 секунд до 3 минут (более 2 минут от forcegcperiod ), объекты удаляются с помощью gc:

returning memory
scvg0: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg0: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
scvg1: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg1: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
gc9(1): 1+0+0 ms 1 -> 1 MB 4485 -> 2562 (26531-23969) objects 0 handoff
gc10(1): 1+0+0 ms 1 -> 1 MB 2563 -> 2561 (26532-23971) objects 0 handoff
scvg2: GC forced//forcegc (2 minutes) exceeded
scvg2: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
gc3(1): 0+0+0 ms 381 -> 381 MB 206 -> 206 (252-46) objects 0 handoff
scvg2: GC forced
scvg2: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
getting memory

Память по-прежнему не освобождена, но GC помечает область памяти как неиспользуемую. Освобождение начнется, когда используемый диапазон не используется и старше, чем limit . Из кода мусорщика:

if(s->unusedsince != 0 && (now - s->unusedsince) > limit) {
   //...
    runtime·SysUnused((void*)(s->start << PageShift), s->npages << PageShift);
}

Такое поведение, конечно, может меняться со временем, но, надеюсь, теперь вы почувствуете, что объекты отбрасываются силой, а когда нет.

Как указано zupa, освобождение объектов может не вернуть память в операционную систему, поэтому в некоторых системах вы не видите изменений в использовании памяти. Это похоже на план 9 и Windows в соответствии с этой нитью на golang-nuts .

34
добавлено
В Windows с версии 1.1 сборка мусора не возвращается в ОС. Человек, который стоил мне дня, чтобы выследить. groups.google.com/forum/#!topic/golang-nuts/ vfmd6zaRQVs
добавлено автор zupa, источник
Рад, что он работал с наконечником. Г-н, кажется, совершенно неполный, да. Если вам интересно, вы можете посмотреть функцию scanblock GC, чтобы увидеть, как он находит ссылки.
добавлено автор nemo, источник
@zupa Очень интересно. Обновил мой ответ с этой информацией.
добавлено автор nemo, источник
спасибо за объяснение, как я понял, GC не очень полно сейчас
добавлено автор duganets, источник
Я написал программу, которая использует много памяти, при запуске с go1.0.3 в OSX-программе паника посреди вычислений после следующей попытки выделить больше памяти (около 1.5Gb). Я сильно оптимизировал для повторного использования как можно больше объектов и структур, но все же имел исключение памяти. Затем я клонировал последний выпуск go и создал его из источника. Запустив последнюю версию go, мой код потребляет столько памяти, сколько ему нужно (2.2Gb), и успешно завершает вычисления.
добавлено автор duganets, источник
Я думаю, что я столкнулся с такой проблемой code.google.com/p/go/issues/…
добавлено автор duganets, источник
Привет ! Не могли бы вы обновить свой ответ о том, как работает gc сегодня? Благодаря !!
добавлено автор Azr, источник

Чтобы в конечном итоге (принудительно) собрать неиспользуемую память, вы должны вызвать runtime.GC() </а>.

variable = nil may make things unreachable and thus eligible for collection, but it per se doesn't free anything.

15
добавлено
Это уже не правильно, вы должны использовать FreeOSMemory , чтобы вернуть память в ОПЕРАЦИОННЫЕ СИСТЕМЫ.
добавлено автор OneOfOne, источник
@OneOfOne любая идея, почему runtime.GC() больше не работает? FreeOSMemory вызывает freeOSMemory , который является Реализован во время выполнения пакета , что это значит?
добавлено автор paradite, источник
Go, go!
Go, go!
2 417 участник(ов)

Русскоязычная группа, посвящённная Golang. Для вакансий: @gogetajob Правила: #gogorules О вакансиях: #go_вакансия_правила Не приветствуются: - оскорбления - nsfw контент - флуд, флейм и спам - избыток оффтоп тем - политика Тиран чатика: @twentydraft

Golang Jobs and Freelance
Golang Jobs and Freelance
760 участник(ов)

Jobs and freelance for golang developers See also @golangjobfeed

Go Get A Job
Go Get A Job
501 участник(ов)

Филиал @gogolang Тираны чатика те же :)