2017-09-21 06:47:23 zundaの投稿 zundan@mastodon.zunda.ninja

にゃーん

status_idsを.compactするようになった(c7cd5624)効果。95パーセンタイルでもた応答時間のスパイクがずいぶん減りました。これはプルリクエストを出しても良いのではないかと思います @unarist さん!https://github.com/zunda/mastodon/commit/c7cd562442411f4f22c8f653a51ac2c3611cca77 https://mastodon.zunda.ninja/media/4bCbWTuFUJCQGmFFD6g

Compact status_ids in StatusRelationshipsPresenter · zunda/mastodon@c7cd562

次のホットスポットはApi::V1::Timelines::PublicController#show。Scout良いんだけどお金をけちってるので今はスタックトレースやらSQLクエリやら見られません。rack-timeout厳しくしていくつかひっかけてみようかな。 https://mastodon.zunda.ninja/media/jkcoefPHCvfv2ywEV74

Rack::Timeout.service_timeoutを180秒から90秒に、Rack::Timeout.wait_timeoutを120秒から60秒にしてみました。タイムアウトするとたまにデータベース接続がリークするようなので、あんまり頻繁にはタイムアウトさせたくないんだよね。

仕事用の電話番号に銀行から電話がかかってきたんだがなんぞー。同じ番号を前に使ってた人が番号を変え忘れたんだろうな。

\テスト/ \ですと/ ←うるさい

$ sync;sync;sync;sudo reboot (-人-)

UTC+9のみなさまおはますー

@h_gocchi まーす! 東京周辺はところによりにわか雨な感じかな?

commit d68df88d4e3da89cdc572d802ac69589dac76be4
Author: Eugen Rochko
Date: Wed Sep 20 19:08:20 2017 +0200

Disable private status federation over OStatus (#5027)

2017-09-21 14:45:34 おさの投稿 osapon@mstdn.nere9.help

SubwayTooterの通知アイコンって牙だったのか。なんで天使の羽?とか思っていた。

.oO(吹き出しだと思ってました)

いくつかバージョンを下げてるインスタンスがあるのねー

Dockerだとログはどっかなー

バルす?

ぽにゅかあ。観てみたいなあ

500エラーのノーティフィケーションが表示されたような気がしてピチピチしながらログを確認しに行く

きたきた

method=GET path=/api/v1/accounts/4118/statuses

Rack::Timeout::RequestTimeoutException (Request waited 16ms, then ran for longer than 59984ms):rack-timeout
app/controllers/application_controller.rb:89:in `cache_collection'
app/controllers/api/v1/accounts/statuses_controller.rb:26:in `cached_account_statuses'
app/controllers/api/v1/accounts/statuses_controller.rb:22:in `load_statuses'
app/controllers/api/v1/accounts/statuses_controller.rb:11:in `index'

クエリ見えた。らっきー:

SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses" LEFT OUTER JOIN mentions ON statuses.id = mentions.status_id AND mentions.account_id = ? WHERE "statuses"."account_id" = ? AND ("statuses"."visibility" IN (?) OR "mentions"."id" IS NOT NULL) ORDER BY "statuses"."id" DESC, "statuses"."visibility" DESC LIMIT ?

Api::V1::Timelines::PublicController#showも見ておこう

/app/controllers/application_controller.rb in cache_collection at line 89
/app/controllers/api/v1/timelines/public_controller.rb in cached_public_statuses at line 20
/app/controllers/api/v1/timelines/public_controller.rb in load_statuses at line 16
/app/controllers/api/v1/timelines/public_controller.rb in show at line 9

で、

SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses" LEFT OUTER JOIN "accounts" ON "accounts"."id" = "statuses"."account_id" WHERE ("statuses"."local" = ? OR "statuses"."uri" IS NULL) AND "statuses"."visibility" = ? AND (statuses.reblog_of_id IS NULL) AND (statuses.reply = FALSE OR statuses.in_reply_to_account_id = statuses.account_id) AND "accounts"."silenced" = ? ORDER BY "statuses"."id" DESC LIMIT ?

が10,816.7 msかけて40行返してる例があった。

TagsController#showでは

/app/views/stream_entries/_status.html.haml in _app_views_stream_entries__status_html_haml__1109947158956352113_70080898259740 at line 37
/app/views/tags/show.html.haml in _app_views_tags_show_html_haml__3007356823649727115_70080653018080 at line 15

が1,092.0 msずつ20回呼ばれたようだ。

New RelicもいいけどScoutもいいよ

iTerm2を更新した

おー!動画プレイヤーが良い感じになってる(いまさら)

一度走らせたら失敗したテストが二回目以降ずーっと成功する件について

bundle exec rake parallel:create parallel:load_schema parallel:prepare 直後に bundle exec rake spec すると /spec/controllers/api/v1/accounts/relationships_controller_spec.rb:53 が、実際の値が1大きくて落ちるようだ。

二回目に走らせたら ./spec/workers/scheduler/subscriptions_scheduler_spec.rb:16 が The request POST http://hub.example.com/ was expected to execute 1 time but it executed 0 times って。あれれー?

次はまた./spec/controllers/api/v1/accounts/relationships_controller_spec.rb:53

次は全通し

テストの走行順に依るんだろうな

masterブランチでrebase upstream/masterする前にfetch upstreamしてなかった件が発覚

おーっと。masterだとテストは全部通りますたー。.compactするのに合わせてテストを書き換えないといけないんだね(明日にしよう…