最適化 #991
完了
Retriever.#Modelを呼び出すと毎回ObjectSpace.each_objectを内部で呼び出していて、処理がかなり遅い
0%
説明
ObjectSpace.each_objectを使って、slugに対応するModelクラスを得ているが、each_objectは低速なうえ、ヒープを全て参照してしまうのでメモリの速度に引きずられそう。
単にHashにキャッシュしておけば高速化できるので、ちょっとやってみる。
toshi_a 初音 さんがほぼ8年前に更新
- 担当者 を toshi_a 初音 から Izumi Tsutsui に変更
topic/991-too-many-inspection-objectspace というブランチで修正したので、そっちの環境で試してもらっていいですか
Izumi Tsutsui さんがほぼ8年前に更新
発生状況¶
定性的な話ばかりですが状況拾っておきます
- もともとは 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 のネットブックあるので、それで試すのが良さそうですね……。
toshi_a 初音 さんがほぼ8年前に更新
まとめありがとうございます。
プロファイラでも3.5.3ではかなり時間がかかっているeach_objectの呼び出しが400回前後あるのが3回まで減っており、ボトルネックが解消されていました。私の環境では特に体感できませんでしたが、スワップしているなどメモリ領域へのアクセスが極端に遅いケースでは体感できる程度に違いが出る可能性はあります。
もしあまり効果がなかったとしても、悪くなってそうということがなければこのままmergeしてしまうと思いますが、しばらく検証してもらっていいですか。
Izumi Tsutsui さんがほぼ8年前に更新
ネットブックで起動してみたのですが、うちのは 2GB載っているのと NetBSD で軽めな環境なせいか
起動直後はほとんどスワップ使っていなくて比較ができそうなほど差がはっきりしないという感じでした。
リストのキャッシュを消した状態で2つのリストの初回取得時にどれくらい止まるか、を見ればわかるかも?
ある程度の時間TLを流して、キャッシュされているが古いデータがほとんど参照されない状態になって、
それらがまとめてスワップに放り込まれている状態になってから全参照（リストの定期取得とか）が発生、
というシナリオだとすると、まる一日くらいは流さないと体感できないかもしれません。
Izumi Tsutsui さんがほぼ8年前に更新
重くなった要因の1つとして
mikutter_slack プラグインを入れていた
という要素もあるかもしれないのであわせて見てみます
Izumi Tsutsui さんがほぼ8年前に更新
とりあえずまる一日過ぎた段階ではプチフリは起きていないような感じです。
以前と比べてメモリ使用量も減っているような気がしますが、気のせいかも……
（相変わらず数字がないレポート）
Izumi Tsutsui さんがほぼ8年前に更新
- ステータス を 実装待ち から 解決 に変更
- 以前のように数秒止まる、という現象は発生していない
- リストの定期間隔取得でちょっと重くなる現象は観測されているがコンマ1,2秒というくらいで復帰する
という定性的感覚的な判定では問題なくなっていると言って良いと思います。