top コマンドで得られる結果をどう見ていけばいいのかわからないので、とりあえず視覚化した

top コマンドで得られる結果をどう見ていけばいいのかわからないので、とりあえず視覚化した

もともと一つの処理であるとか、一つのメソッドであるとかの処理時間には興味があって、測定などをしていました。ActiveRecord を使うにあたって発行クエリを抑えることにより、本当に早くなるのか確かめたりするのがすきです。

全体的なパフォーマンスを測定し、改善に繋げる知識がない

そういう局所的なものは何度もまわして処理時間を取って、という方法でなんとなく測定をできるのですが、Web アプリケーション全体の負荷の把握方法や、運用においてのスローダウンの原因究明などに使える情報などの取得については、ほとんど知識がありません。

ぐぐることにより、各種コマンドで負荷を数値化できることはすぐにわかりましたが、その数値が何を意味するかはよくわかりません (負荷が高い低いぐらいはわかるが、どういう経緯でそうなったかわからない)。さらに、これを蓄積し、それをそのまま眺めたところで、勘の悪いわたしが何かを把握できるとは思えなかったので、せめてわかりやすい形に変換しようと、最近取り組んでいたのが top のグラフ化です。

f:id:mmmpa:20161211200646g:plain

これは Chrome で 70 タブぐらい一気に開いたときの図です。CPU は大暴れ、メモリ消費もアゲアゲで大変きれいですね。

どこかにありそうなソフトですが、こういうラッパーのようなものをつくると、そのコマンドと仲良くなれるのでまるっきり無駄ということはないと信じています。

勉強

現段階では単にグラフ化しただけなので、ここからどうつなげていくかは要勉強というところですが、これだけでも Chrome の大量のタブは大量のプロセスを産んで、それぞれ個別にちょっとずつメモリを消費して大変なことになるので、個別のメモリに注目していてはその本当の負荷はわからないということがわかりました。

いまは、翔泳社 + kindle のポイント還元セールで入手した以下の本で、パフォーマンスのあれこれに関する勘所を把握しようとしています。各分野においての基礎知識を軽く説明ののちに、パフォーマンスなどの原因や解決法の話に入るので、まるでわからない状態で聞かされることがなく、いい本だと思います。

絵で見てわかるシステムパフォーマンスの仕組み

絵で見てわかるシステムパフォーマンスの仕組み

その他

プログラムのほうは、バックエンドは Go から SSH で対象サーバーに接続していますが goroutine の不適切使用により、同データへの同時アクセスが原因と思われる panic というのを経験して、非同期処理の経験値がアップしました。よかったですね。