Comment analyser golang de la mémoire?

Le tas de profil montre active de la mémoire, de la mémoire à l'exécution croit est en cours d'utilisation par le programme de go (c'est à dire: n'a pas été recueillies par le garbage collector). Lorsque le GC ne se recueillir à la mémoire que le profil se rétrécit, mais pas de mémoire est renvoyé dans le système. Votre les allocations futures essayez d'utiliser la mémoire de la piscine de déjà recueilli des objets avant de demander au système pour plus d'.

De l'extérieur, cela signifie que votre programme est l'utilisation de la mémoire seront en augmentation, ou de rester au niveau. Ce que le système se présente comme le "Résident" Taille de votre programme est le nombre d'octets de RAM est attribué à votre programme si elle tient à usage allez valeurs ou celles recueillies.

La raison pour laquelle ces deux nombres sont souvent très différents, parce que:

1. La GC de la collecte de la mémoire n'a pas d'effet sur la vue de l'extérieur du programme
2. Fragmentation de la mémoire
3. Le GC ne fonctionne que lorsque la mémoire dans l'utilisation des doubles d'utiliser la mémoire après la précédente GC (par défaut, voir: http://golang.org/pkg/runtime/#pkg-overview)

Si vous voulez une répartition précise de comment Aller voit le mémoire que vous pouvez utiliser le moteur d'exécution.ReadMemStats appel: http://golang.org/pkg/runtime/#ReadMemStats

Sinon, puisque vous êtes à l'aide de web basé sur le profilage si vous pouvez accéder au profilage de données par le biais de votre navigateur à: http://10.10.58.118:8601/debug/pprof/ , en cliquant sur le tas de lien vous montrera le débogage de vue du tas de profil, qui a une impression d'une exécution.MemStats structure au fond.

Le moment de l'exécution.MemStats documentation (http://golang.org/pkg/runtime/#MemStats) a l'explication de tous les champs, mais ce qui est intéressant pour cette discussion sont les suivants:

• HeapAlloc: essentiellement, ce que le profiler vous donne (active la mémoire heap)
• Alloc: similaire à HeapAlloc, mais pour tous les go de mémoire gérée
• Sys: la quantité totale de mémoire (espace d'adressage) a demandé l'OS

Il y aura toujours des divergences entre les Sys, et que les OS des rapports parce que ce qui va demande du système, et ce que l'OS lui donne ne sont pas toujours les mêmes. Aussi CGO /syscall (par exemple: malloc /mmap) de la mémoire n'est pas suivi par aller.

J'ai toujours été confus au sujet de la croissance résidentielle de la mémoire de mon Go applications, et enfin, j'ai eu à apprendre les outils de profilage qui sont présents dans Aller de l'écosystème. Runtime fournit de nombreuses mesures en une moment de l'exécution.Memstats structure, mais il peut être difficile à comprendre lequel d'entre eux peut vous aider à trouver les raisons de la croissance de la mémoire, de sorte que certains des outils supplémentaires sont nécessaires.

De profilage de l'environnement

Utilisation https://github.com/tevjef/go-runtime-metrics dans votre application. Par exemple, vous pouvez mettre ceci dans votre 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
    }
}

Exécuter InfluxDB et Grafana dans Docker conteneurs:

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

Ensemble de l'interaction entre des Grafana et InfluxDB Grafana (Grafana page principale -> en Haut à gauche -> Sources de données -> Ajouter une nouvelle source de données):

Importation de tableau de bord #3242 de https://grafana.com (Grafana page principale -> en Haut à gauche -> tableau de bord -> Import):

Enfin, le lancement de votre application: il transmettra exécution des métriques de la contenerized Influxdb. Mettre votre application en vertu de l'raisonnable de la charge (dans mon cas c'était assez petite de 5 RPS pour une à plusieurs heures).

Mémoire analyse de la consommation d'

1. Sys (le synonim de RSS) de la courbe est assez similaire à HeapSys courbe. S'avère que l'allocation dynamique de la mémoire a été le principal facteur de la croissance globale de la mémoire, de sorte que la petite quantité de mémoire consommée par pile variables semblent être constante et peut être ignoré;
2. La quantité constante de goroutines garantit l'absence de goroutine des fuites et des variables de pile fuite;
3. Le montant total de l'allocation des objets reste le même (il n'y a aucun point en tenant compte des fluctuations) au cours de la durée de vie du processus.
4. Le plus fait surprenant: HeapIdle est croissante avec le même taux que l' Sys, tandis que HeapReleased est toujours à zéro. Évidemment runtime ne revient pas en mémoire d'OS à tous les , au moins dans les conditions de ce test:

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.

Pour ceux qui cherche à étudier le problème de la consommation de mémoire je vous recommande de suivre les étapes dans l'ordre pour exclure certaines erreurs triviales (comme goroutine de fuite).

La libération de la mémoire explicite

Il est intéressant de noter que l'on peut réduire considérablement la consommation de mémoire avec des appels explicites à debug.FreeOSMemory():

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

En fait, cette approche a sauvé environ 35% de mémoire en comparaison avec les conditions par défaut.