2017-01-09 4 views
2

私たちは、同時要求を受け取り、要求を処理して(大きなオブジェクトを作成します - ツリー)golangを使用してサーバーを開発し、返信を返します。しかし、オブジェクトはガベージコレクションされません。だから、私はメモリ内に存在するオブジェクトを分析することに決めました。で起動するには、私は簡単なプログラムヒープダンプを視覚化するには?

package main 

import (
    "fmt" 
    "io/ioutil" 
    "os" 
    "runtime/debug" 
) 

func main() { 
    var i_am_a int = 10 
    _ = i_am_a 
    func() { 
     f, err := os.Create("dump") 
     defer f.Close() 
     if err != nil { 
      panic(err) 
     } 
     debug.WriteHeapDump(f.Fd()) 
    }() 

    b, err := ioutil.ReadFile("dump") 
    if err != nil { 
     panic(err) 
    } 
    fmt.Print(string(b)) 

} 

を書いたしかし、私はプレゼンテーションは理解できなかった(https://github.com/golang/go/wiki/heapdump13を - これは助けにはなりませんでした)。私が望むのは、メモリ(大きなオブジェクト)から、オブジェクトのルートアドレスを保持する場所(アプリケーションコード内の変数)までトレースすることです。だから私は参照を解放することができますし、それがサイクルでそれを収集するGCさせます。ヒープダンプを視覚化する最新のツールはありますか?またはこの問題に対するより良いアプローチがありますか?

+0

このリンクはあなたのGoメモリ分析に役立ちますか? https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs –

+0

@JeandeyBoris、私はすでにそのトリックを試みました。しかし、それらのどれも実際には役に立たない。私が理解できなかったヒープダンプだけが役立つ情報です。 – Spartan

答えて

1

現在、問題の完全な解決策はありません。 newest heap dump formatは、以前利用可能な情報の一部がランタイムによって追跡されなくなったことを説明しています。

Go Issue 16410には、進行中の作業に関する多くの詳細と情報があります。

つのツール - 進行中の作業 - あなたはnet/pprofパッケージを使用することができますgoheapdump

-1

で役立つかもしれません。ヒープ/ CPUプロファイルをダンプするには、https://blog.golang.org/profiling-go-programsの手順に従ってください。

go tool pprof binary dumpfileを使用してダンプファイルを分析できます。インタラクティブな分析ツールにwebと入力すると、Webブラウザでコールグラフが表示されます。

関連する問題