Debugging 100% CPU usage in production Ruby on Rails systems
Sam Saffron Programming, Technology and the Art of Hacking Today I noticed one of our customer containers was running really high on CPU. # top -bn1 190 discour+ 20 0 2266292 205128 15656 S 86.7 0.3 9377:35 ruby # ps aux discour+ 190 19.4 0.3 2266292 207096 ? Sl 2017 9364:38 sidekiq 5.0.5 discourse [1 of 5 busy] Looks like sidekiq is stuck on a job. Where is it stuck? Usually, this is where the st
Webアプリケーションの遅い処理を特定する話 - MEDLEYオフィシャルブログ
こんにちは、開発本部で「ジョブメドレー」の開発を担当している稲本です。 先日、社内で行っているTechLunchという勉強会で「Webアプリケーションの遅い処理を特定する話」という話をしました。 タイトルの意味する範囲が広めなので概要を記載すると以下の通りです。 NewRelicから処理速度を見ていく ChromeDeveloperTools処理速度を見ていく RoR関連のプロファイラから処理速度を見ていく 上記の様にClientからServer, Applicationまでプロファイリングを行い遅い処理を特定していく流れの話をしました。 なぜこの話をしようと思ったのか 弊社ではフロントエンドエンジニア、サーバサイドエンジニアなどのポジションが明確には分かれておらず、どのバックグラウンドを持った人間も両方開発に携わる方針のため、エンジニア同士が、お互いの得意分野を補い合いながら、各々業務や
Ruby/Railsでの高速化の際に使うgem達 - Qiita
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
Speeding up Rails 4.2
Sam Saffron Programming, Technology and the Art of Hacking Recently Godfrey Chan got Discourse working on Rails Master. It was a rather long task that involved some changes to Discourse internals and some changes to Rails internals. Knowing Rails 4.2 was just around the corner I decided that it seemed like the perfect time to see how performance is. Seeing Rails 4.2 contains the adequate record pa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tmm1/stackprof: a sampling call-stack profiler for ruby 2.2+
