Wie zu analysieren, golang Speicher?

Heap Profil zeigt aktive Arbeitsspeicher der Laufzeitumgebung glaubt, wird von der go-Programm (sprich: noch nicht erhoben wurden, durch den garbage collector). Wenn der GC nicht sammeln-Speicher das Profil verkleinert, aber kein Speicher an das system zurückgegeben. Ihre zukünftige Zuweisungen werden versuchen, die Verwendung von Speicher aus dem pool der bisher gesammelten Objekte, bevor du das system für mehr.

Von außen, das bedeutet, dass Ihr Programm-Speicher verwenden, wird Sie entweder steigen, oder bleiben Ebene. Was die außerhalb der system präsentiert als die "Resident Size" des Programms ist die Anzahl der bytes des RAM zugeordnet ist, zu Ihrem Programm, ob es hält, in-go-Werte, die gesammelt oder lieben.

Der Grund, warum diese beiden zahlen sind oft ganz anders sind da:

1. Der GC sammeln-Speicher hat keine Auswirkungen auf die Außenansicht der Programm
2. Fragmentierung des Speichers
3. Der GC läuft nur, wenn der Speicher verdoppelt den Speicher, der nach dem früheren GC (standardmäßig finden Sie unter: http://golang.org/pkg/runtime/#pkg-overview)

Wenn Sie möchten, eine genaue Aufschlüsselung, wie Gehen, sieht der Arbeitsspeicher der Laufzeitumgebung.ReadMemStats nennen: http://golang.org/pkg/runtime/#ReadMemStats

Alternativ, da Sie über eine web-basierte profiling, wenn Sie den Zugriff auf die profiling-Daten durch Ihren browser an: http://10.10.58.118:8601/debug/pprof/ Klick auf die heap-link erhalten Sie die debugging-Ansicht der heap Profil, die hat einen Ausdruck, der eine Laufzeit.MemStats Struktur an der Unterseite.

Die Laufzeit.MemStats Dokumentation (http://golang.org/pkg/runtime/#MemStats) hat die Erklärung aller Felder, aber die interessant sind für diese Diskussion sind:

• HeapAlloc: im wesentlichen, was der profiler gibt Ihnen die (aktiv-heap-Speicher)
• Alloc: ähnlich HeapAlloc, aber für alle verwalteten Speicher
• Sys: die Gesamtmenge an Speicher (Adressraum) forderte von der OS

Wird es immer noch Diskrepanzen zwischen Sys und was das OS meldet das da was Gehen, fragt das system, und was das OS gibt es nicht immer die gleichen. Auch CGO /syscall (zB: malloc /mmap) Speicher wird nicht aufgespürt durch gehen.

Ich war immer verwirrt über die wachsende Wohn-Erinnerung an meine Gehe zu Programme, und schließlich musste ich lernen, die profiling-tools, die vorhanden sind, Gehen ökosystems. Runtime bietet viele Metriken innerhalb einer - Laufzeit.Memstats Struktur, aber es kann schwierig sein zu verstehen, welche von Ihnen können helfen, um herauszufinden, die Gründe der Speicher-Wachstum, so werden einige weitere tools benötigt werden.

Profiling-Umgebung

Verwenden https://github.com/tevjef/go-runtime-metrics in Ihrer Anwendung. Zum Beispiel, können Sie dieses in Ihrem main:

import(
    metrics "github.com/tevjef/go-runtime-metrics"
)
func main() {
    //...
    metrics.DefaultConfig.CollectionInterval = time.Second
    if err := metrics.RunCollector(metrics.DefaultConfig); err != nil {
        //handle error
    }
}

Laufen InfluxDB und Grafana innerhalb Docker Behälter:

docker run --name influxdb -d -p 8086:8086 influxdb
docker run -d -p 9090:3000/tcp --link influxdb --name=grafana grafana/grafana:4.1.0

Eingerichtet Interaktion zwischen Grafana und InfluxDB Grafana (Grafana main Seite -> Oben Links -> Datasources -> Add new datasource):

Importieren von dashboard - #3242 von https://grafana.com (Grafana main Seite -> Oben Links -> Dashboard -> Importieren):

Schließlich, starten Sie Ihre Anwendung: es wird übertragen-Laufzeit-Metriken, um die contenerized Influxdb. Legen Sie Ihre Anwendung unter angemessener Belastung (in meinem Fall war es ziemlich klein - 5 RPS für ein paar Stunden).

Speicherverbrauch Analyse

1. Sys (das synonim von RSS) - Kurve ist sehr ähnlich zu HeapSys Kurve. Stellt sich heraus, dass die dynamische Speicherverwaltung war der wichtigste Faktor der gesamten Speicher-Wachstum, so dass die kleine Menge an Speicher verbraucht, stack-Variablen scheinen eine Konstante und kann ignoriert werden;
2. Die Konstante Menge von goroutines garantiert die Abwesenheit von goroutine leaks /stack-Variablen Leck;
3. Der Gesamtbetrag der zugewiesenen Objekte bleibt gleich (es gibt keinen Punkt bei der Berücksichtigung der Schwankungen) während der Lebensdauer des Prozesses.
4. Die meisten überraschende Tatsache: HeapIdle wächst mit der gleichen rate wie ein Sys, während HeapReleased ist immer null. Offensichtlich runtime nicht zurück-Speicher für OS an alle , zumindest unter den Bedingungen dieses Tests:

HeapIdle minus HeapReleased estimates the amount of memory    
that could be returned to the OS, but is being retained by
the runtime so it can grow the heap without requesting more
memory from the OS.

Für diejenigen, die versuchen, das problem zu untersuchen Speicherverbrauch würde ich empfehlen, Folgen Sie den beschriebenen Schritten, um auszuschließen, einige triviale Fehler (wie goroutine Leck).

Freigeben von Speicher explizit

Es ist interessant, dass die, die können erheblich reduzieren den Speicherverbrauch mit der expliziten Aufrufe debug.FreeOSMemory():

//in the top-level package
func init() {
   go func() {
       t := time.Tick(time.Second)
       for {
           <-t
           debug.FreeOSMemory()
       }
   }()
}

In der Tat, dieser Ansatz gespart über 35% der Speicher im Vergleich mit den Standard-Bedingungen.