15

私はソーシャル グラフ データを分析するコードの最適化に取り組んできました ( https://blog.golang.org/profiling-go-programsから多くの助けを借りて)。

すべてのデータは最初に db からメモリにロードされ、そこからのデータ分析は CPU バウンドのように見えます (最大メモリ消費量 < 10MB、CPU1 @ 100%)

しかし今、私のプログラムの時間のほとんどは、runtime.osyield と runtime.usleep にあるようです。それを防ぐ方法は何ですか？

私は GOMAXPROCS=1 を設定しましたが、コードはゴルーチンを生成しません (golang ライブラリが呼び出す可能性があるものを除く)。

これは、pprof からの私のトップ 10 出力です

(pprof) top10
62550ms of 72360ms total (86.44%)
Dropped 208 nodes (cum <= 361.80ms)
Showing top 10 nodes out of 77 (cum >= 1040ms)
      flat  flat%   sum%        cum   cum%
   20760ms 28.69% 28.69%    20850ms 28.81%  runtime.osyield
   14070ms 19.44% 48.13%    14080ms 19.46%  runtime.usleep
   11740ms 16.22% 64.36%    23100ms 31.92%  _/C_/code/sc_proto/cloudgraph.(*Graph).LeafProb
    6170ms  8.53% 72.89%     6170ms  8.53%  runtime.memmove
    4740ms  6.55% 79.44%    10660ms 14.73%  runtime.typedslicecopy
    2040ms  2.82% 82.26%     2040ms  2.82%  _/C_/code/sc_proto.mAvg
     890ms  1.23% 83.49%     1590ms  2.20%  runtime.scanobject
     770ms  1.06% 84.55%     1420ms  1.96%  runtime.mallocgc
     760ms  1.05% 85.60%      760ms  1.05%  runtime.heapBitsForObject
     610ms  0.84% 86.44%     1040ms  1.44%  _/C_/code/sc_proto/cloudgraph.(*Node).DeepestChildren
(pprof)

_ /C_/code/sc_proto/* 関数は私のコードです。

そしてウェブからの出力： ウェブからの出力

(こちらの SVG バージョンのグラフ: https://goo.gl/Tyc6X4 )

4

1 に答える 1

10

自分で答えを見つけたので、同様の問題を抱えている他の人のためにここに投稿します。そして、私を正しい道に導いてくれた@JimBに特に感謝します。

グラフからわかるように、osyield と usleep につながるパスはガベージ コレクション ルーチンです。このプログラムは、多くのポインタを生成するリンク リストを使用していたため、gc に多くの作業が発生し、混乱を解消している間にコードの実行がブロックされることがありました。

最終的に、この問題の解決策はhttps://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs (素晴らしいリソースでした) から得られました。そこにあるメモリプロファイラーに関する指示に従いました。ポインターのコレクションをスライスに置き換えるという推奨事項により、ガベージ コレクションの問題が解消され、コードが大幅に高速になりました。

于 2016-02-02T17:57:48.817 に答える