Project

General

Profile

最適化 #991

Retriever.#Modelを呼び出すと毎回ObjectSpace.each_objectを内部で呼び出していて、処理がかなり遅い

Added by toshi_a 初音 over 2 years ago. Updated over 2 years ago.

Status:
終了
Priority:
通常
Assignee:
Target version:
Start date:
2017-03-05
Due date:
% Done:

0%

プラグイン名:

Description

ObjectSpace.each_objectを使って、slugに対応するModelクラスを得ているが、each_objectは低速なうえ、ヒープを全て参照してしまうのでメモリの速度に引きずられそう。
単にHashにキャッシュしておけば高速化できるので、ちょっとやってみる。

Associated revisions

Revision 91988214 (diff)
Added by toshi_a 初音 over 2 years ago

Retriever.Modelの結果をキャッシュする refs #991

History

#1

Updated by toshi_a 初音 over 2 years ago

  • Assignee changed from toshi_a 初音 to Izumi Tsutsui

topic/991-too-many-inspection-objectspace というブランチで修正したので、そっちの環境で試してもらっていいですか

#2

Updated by Izumi Tsutsui over 2 years ago

発生状況

定性的な話ばかりですが状況拾っておきます

  • もともとは 3.5 になってからという気もするけれどあまり定かでない
  • 常に遅いのではなくて、何かが裏で走っているような感じで遅くなる
  • 確証はないけれど、以下のいずれかで重くなる?
    • リストの定期更新がかかって、リストのストリームでは取得されないリストメンバーのRTを一気に受信した時
    • 最近 Mentions として通知されるようになったけれども UserStream に載らないコメント付きRTが複数発生したものを rest で取得した時
  • 発生すると以下の操作がいずれも重くなる
    • ツイート入力(日本語変換含む)
    • TLのホイールスクロール
    • URIをポイントした時のマウスカーソル変化
    • 画像を開く
  • プチフリ中に操作しても反応しないが、操作自体は裏でたまっているようで、プチフリから開放されるとたまっていた操作が一気に実行される(スクロール・ツイート入力・ブラウザを開く 等々)

今回のとしぁさん駆動の発端ツイートはこれ

mikutterのメモリ消費問題は解決したけれど、 rest やリストの定期更新がかかって一斉に複数アイコンロードが発生した時にプチフリというか秒単位でフリーズする現象が起きている気がする(感覚的定性的な役に立たないレポート)
18:39 - 2017年3月3日

toshi_a 初音 リストのストリームはRTを送ってこないので、リストの定期更新時間が来ると一斉にRTされた分のアイコンがロードされるっぽいのですが、そこで むぎゅぎゅ となってる印象(マウスのホイールの調子も悪いのでどっちが原因で動かないのか一瞬わからなくなる)
18:41 - 2017年3月3日


Atom なネットブックに入れ直した室長さんもこんなレポート

キャッシュを消したからだろうけれどアイコンの読み込みがほとんどできない
1:17 - 2017年3月5日

toshi_a 初音 ちょいちょい読み込んでいっているのでしばらくしたら治るね
1:18 - 2017年3月5日

@brsywe 3.5で無駄に何回も読み込みに行くバグが直ったので回線には優しくなったんだが、同時にCPUに負荷がかかるようになった可能性があるとつついさんから指摘があったな、それかも
1:19 - 2017年3月5日

まっさらな状態のUbuntuにmikutter入れた直後、アイコンを取りに行くのにCPUか回線を使いすぎていて新たな画像が開けない状態になる
2:04 - 2017年3月5日


としぁさんの分析

@tsutsuii 今回修正したメソッドは最悪の場合ヒープを全て走査してしまうので、スワップしていると酷いことになりそう
17:32 - 2017年3月5日

toshi_a 初音 あー、スワップはそれなりに使われていて、日本語変換も詰まるところからするとそれっぽい気はしますね……
17:33 - 2017年3月5日


うちにも Atom N455 のネットブックあるので、それで試すのが良さそうですね……。

#3

Updated by toshi_a 初音 over 2 years ago

まとめありがとうございます。

プロファイラでも3.5.3ではかなり時間がかかっているeach_objectの呼び出しが400回前後あるのが3回まで減っており、ボトルネックが解消されていました。私の環境では特に体感できませんでしたが、スワップしているなどメモリ領域へのアクセスが極端に遅いケースでは体感できる程度に違いが出る可能性はあります。

もしあまり効果がなかったとしても、悪くなってそうということがなければこのままmergeしてしまうと思いますが、しばらく検証してもらっていいですか。

#4

Updated by Izumi Tsutsui over 2 years ago

ネットブックで起動してみたのですが、うちのは 2GB載っているのと NetBSD で軽めな環境なせいか
起動直後はほとんどスワップ使っていなくて比較ができそうなほど差がはっきりしないという感じでした。
リストのキャッシュを消した状態で2つのリストの初回取得時にどれくらい止まるか、を見ればわかるかも?

ある程度の時間TLを流して、キャッシュされているが古いデータがほとんど参照されない状態になって、
それらがまとめてスワップに放り込まれている状態になってから全参照(リストの定期取得とか)が発生、
というシナリオだとすると、まる一日くらいは流さないと体感できないかもしれません。

#5

Updated by Izumi Tsutsui over 2 years ago

重くなった要因の1つとして
mikutter_slack プラグインを入れていた
という要素もあるかもしれないのであわせて見てみます

#6

Updated by Izumi Tsutsui over 2 years ago

とりあえずまる一日過ぎた段階ではプチフリは起きていないような感じです。
以前と比べてメモリ使用量も減っているような気がしますが、気のせいかも……
(相変わらず数字がないレポート)

#7

Updated by Izumi Tsutsui over 2 years ago

  • Status changed from 実装待ち to 解決
起動して5日経過して ruby のメモリ使用量 1.3GB くらいの時点ですが
  • 以前のように数秒止まる、という現象は発生していない
  • リストの定期間隔取得でちょっと重くなる現象は観測されているがコンマ1,2秒というくらいで復帰する

という定性的感覚的な判定では問題なくなっていると言って良いと思います。

#8

Updated by toshi_a 初音 over 2 years ago

  • Status changed from 解決 to 終了

Also available in: Atom PDF