【9月29日のバルス対策について】
Hostdonでは9月29日の朝8:00〜9月30日の朝8:00の24時間の間、バルスによる配送等の遅延を最小限に抑えるため、すべてのインスタンスのSidekiqのプロセス数を2倍に増強し対策をすることになりました。
また、Passengerの設定も一時的に変更します。
よろしくお願いします。
【9月29日のバルス対策について】
Hostdonでは9月29日の朝8:00〜9月30日の朝8:00の24時間の間、バルスによる配送等の遅延を最小限に抑えるため、すべてのインスタンスのSidekiqのプロセス数を2倍に増強し対策をすることになりました。
また、Passengerの設定も一時的に変更します。
よろしくお願いします。
このインスタンスはたぶんPostgresがボトルネックなのでPumsとかSidekiq増やすのは逆効果なんだよな。というわけであしたVACUUM FULL試してみよう。作業中はインスタンスが停止します。
このアカウントは、notestockで公開設定になっていません。
まぁgitなんてリーナス・トーバルズってオッチャンたちが自分たちが作ってるLinux-kernelとかいうやつのバージョン管理したいがために作ったものなのでオッチャンたちが使いやすければよかったみたいなところがありますよね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
昨夜、8:00 UTCごろにVACUUMを走らせてから、若干レスポンスが良くなっているようです。黄色の線はトラッフィク、緑色の棒がActiveRecordの消費時間。あと10分ほどでこのインスタンスをいったん停止させ、VACUUM FULLしてみます。 https://mastodon.zunda.ninja/media/k9wsae2ai6yLCIaAFZ0
$ heroku pg:info
=== DATABASE_URL, PG_HOBBY_BASIC_URL
Plan: Hobby-basic
Status: Available
Connections: 6/20
PG Version: 9.6.1
Created: 2017-04-20 18:31 UTC
Data Size: 276.7 MB
Tables: 35
Rows: 568195/10000000 (In compliance)
$ heroku pg:diagnose
RED: Hit Rate
Name Ratio
────────────────────── ──────────────────
overall index hit rate 0.9311722873276731
overall cache hit rate 0.6373249488053885
GREEN: Connection Count
GREEN: Long Queries
GREEN: Idle in Transaction
GREEN: Indexes
GREEN: Bloat
GREEN: Blocking Queries
GREEN: Sequences
SKIPPED: Load
この指標はVACUUMしても変化しないんだろうけど。
Sidekiqのキューがはけたら通知をトゥートして止めて、って思ってたけどトゥートした時点でまたキューがたまるなw このトゥートの分のキューがはけたあたりで無言で止めまーす。
VACUUM FULLが終わりました。速くなったかな？メンテナンスモードになっていたのは6分30秒ほどでした。
$ heroku maintenance:on
$ heroku logs -t
まだ再試行してるジョブがあるけれどまあいいだろう。
$ heroku ps:scale web=0
$ heroku pg:psql
zundan-mastodon::DATABASE=> VACUUM FULL;
Time: 138591.313 ms
zundan-mastodon::DATABASE=>
zundan-mastodon::DATABASE=> \q
$ TZ=UTC date
Wed Sep 20 18:11:48 UTC 2017
$ heroku ps:scale web=1
Dynoのupを待って、
$ heroku maintenance:off
このアカウントは、notestockで公開設定になっていません。
pg:bloatで見えるwasteはずいぶん小さくなった。pg:diagnoseはやっぱり変化していない。Data Sizeは40MB現象。よしよし。
$ heroku pg:info
=== DATABASE_URL, PG_HOBBY_BASIC_URL
Plan: Hobby-basic
Status: Available
Connections: 5/20
PG Version: 9.6.1
Created: 2017-04-20 18:31 UTC
Data Size: 239.1 MB
Tables: 35
Rows: 573807/10000000 (In compliance)
現在遅いのはApi::V1::NotificationsController#indexとApi::V1::Timelines::PublicController#showあたり。 https://mastodon.zunda.ninja/media/Zy7q-wXM3wNa0xVgb8M
すっごく定期的に遅いです…。今はSubwayTooterは動いていない感じで、どこかでPublicなタイムラインをポーリングしてるんだろうな。 https://mastodon.zunda.ninja/media/_mSZ36QnZxGB_Ui4dwk https://mastodon.zunda.ninja/media/tS8dh8ZL82hIHumT-bg
Database is growing quicker lately. I might have to start paying for a bigger one earlier than I thought... 🤔 https://mastodon.zunda.ninja/media/W4-rIix-wFL4Fto8Ypo
Api::V1::NotificationsController#indexで遅いのはapp/controllers/api/v1/notifications_controller.rbからdef browserable_account_notificationsと辿ってcurrent_account.notificationsあたりかなあ。実装はapp/models/account.rbのhas_many :notificationsっぽい (たいへん)。
実を言うとOStatusはもうだめです。
突然こんなこと言ってごめんね。
でも本当です。
２、３日後にmaster追従勢がビチビチし始めます。
それが終わりの合図です。
程なく大きめのリリースが来るので
気をつけて。
それがやんだら、少しだけ間をおいて
終わりがきます。
このアカウントは、notestockで公開設定になっていません。
遅いApi::V1::NotificationsController#indexのバックトレースが見えた！らっきー！（ちゃんと有料プランにしてないのでトランザクションが多すぎると見えなくなる）
/app/models/status.rb in map at line 177 を見るべきだとのこと。 https://mastodon.zunda.ninja/media/RqAw5sNa1O6S7byWs7c
SQLも見えた。下記が101,527.7 msかけて2701行返したとのこと
SELECT "statuses"."reblog_of_id" FROM "statuses" WHERE ("statuses"."reblog_of_id" = ? OR "statuses"."reblog_of_id" IS NULL) AND "statuses"."account_id" = ? ORDER BY "statuses"."id" DESC
Timelines::PublicController#showではapplication_controller.rb:89が120s。
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 ?
たぶん最近のだけに限定すればいいんだろうけどActiveSupportでどう書くのやらw 仕事にもどろう。
Api::V1::Timelines::HomeController#showでも/app/models/status.rb:177が38秒かけて2702行返した例があった。
SELECT "statuses"."reblog_of_id" FROM "statuses" WHERE ("statuses"."reblog_of_id" IN (?) OR "statuses"."reblog_of_id" IS NULL) AND "statuses"."account_id" = ? ORDER BY "statuses"."id" DESC
遅いエンドポイントへのリクエストが重なってPumaのリクエストのキューが長くなったのが原因だったようです。ならしょーがない← https://mastodon.zunda.ninja/media/gri0_HG0I1B6A4ebcMA
@unarist なーんと！見つかってよかった。
後で自分で見返そうと思って記録しておいたら見ていただいちゃって、どうもありがとうございます！
@unarist diffがあればうちの弱っちいPostgresで試してみることもできますです〜
@unarist とりあえずEXPLAIN ANALYZEです。OR "reblog_of_id" IS NULLを無くすとだいぶ速くなって少しだけ返ってくる行が多いようです。行が多いのがよくわからない…。
https://gist.github.com/zunda/9abfa85dc1f72d037e058d5e481c6585
他のインスタンスへの迷惑はないだろうと思うので、.compact足してしばらく運用してみますね。
@unarist あー、やっぱり。account_idを1にして（ぼっちなので）、reblog_of_idを11にして https://gist.github.com/zunda/9abfa85dc1f72d037e058d5e481c6585 を更新しました。25倍くらい速度が違いますね。これからパッチ適用版にリブートしまーす。
\2017-09-21 03:58このインスタンスにパッチを当てました/
https://github.com/zunda/mastodon/commit/c7cd562442411f4f22c8f653a51ac2c3611cca77
StatusRelationshipsPresenterでstatus_idsがコンパクトになるよ。
@unarist https://github.com/zunda/mastodon/commit/c7cd562442411f4f22c8f653a51ac2c3611cca77 を当てました。しばらく様子を見てみますね。
@hyuki カスタム絵文字は1.6.1のタグが付いた後にマージされた機能です。次のリリースには入りそうですがいつなんだろう
https://github.com/tootsuite/mastodon/pull/4988
https://github.com/tootsuite/mastodon/pull/5002
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
HerokuでMastodon走らせるの楽ですよー。Postgresをまともなのにするとちょっと高いけど。
Redisの稼働状況。使用メモリは25MB中2MB程度、接続数は最大20のうち12程度。
今の10倍くらいの長さのキューを保持できるということは、処理速度が同じだとしてだいたい今の10倍くらいの流速でトゥートが配達されてきても耐えられるということになるのかな？一方、接続数にも少し余裕があるのでSidekiqのスレッド数を増やすこともできそう。 https://mastodon.zunda.ninja/media/b4JWHHFyDLweUCP9wMI
95パーセンタイルでみると、status_idsを.compactするようになって(c7cd5624)から、応答時間のスパイクが減りました。このまま落ち着いてくれてるといいな。 https://mastodon.zunda.ninja/media/t_GCsVJzBnIueUCnoV0
