Debugging Latency in Go 1.11
It is complicated to diagnose and debug complicated systems. It often takes multiple levels of diagnostics data to understand the possible causes of latency issues. A distributed system is made of many servers that are depending on each other to serve a user request. At any time, A process in the system might be handling a large number of requests.In highly concurrent servers, there is no easy way
goで書いたコードがヒープ割り当てになるかを確認する方法 · hnakamur's blog
2018-01-30 はじめに Allocation Efficiency in High-Performance Go Services · Segment Blog という記事を読みました。素晴らしいのでぜひ一読をお勧めします。 この記事は自分の理解と実際に試してみた結果のメモです。 一番のポイントは go build -gcflags '-m' のようにオプションを指定してビルドすればコードのどの箇所でヒープ割り当てが発生したかを確認できるということです。 pprof や go test -benchmem でもヒープ割り当ての発生回数は確認できますが、上の方法ではコードのどこ(何行目の何カラム目)でヒープ割り当てが発生したかとなぜ発生したかの理由を確認できます。 元記事の内容メモ 冒頭にあげた記事を読んで私が理解した内容のメモです。 元記事の全ての内容を書いているわけでないので、元
Go’s march to low-latency GC
We use Go at Twitch for many of our busiest systems. Its simplicity, safety, performance, and readability make it a good tool for the problems we encounter with serving live video and chat to our millions of users. But this isn’t another article about how great Go is for us — it’s about how our use of Go pushes the limits of the current runtime implementation in some dimensions, and how we respond
GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Profiling and Optimizing Go
