自転車で走り回ってingressしてたら膝をやられて引退した
http://www.masking-tape.jp/lineup/mt-foto/foto/ mtブランドのやつ。固定力は弱い。だがそこがいい
ハクバのは湿度40%以下で吸湿力が弱まるので湿度計なしでもお手軽に使えて便利
今の部屋は…ドール全部に服を着せてからでないと、画像を晒すには支障があるな
むしろ背もたれなしの方が腰には良いんだよね。リラックスできないから今は使ってないけど＞椅子
インスタントの袋ラーメンが美味しい季節になりました。それほど高カロリーでもないし
このアカウントは、notestockで公開設定になっていません。
多分フォロワーのブースト解除か何かで発生するんだと思うけどよくわからない
snowflake IDがきてから、HTLが古いトゥートで途切れてそれ以上遡れなくなることが増えた
postgreSQLのパラメータも軽くいじっておいた。pgbouncer前提で最大接続数をすごく絞ってる
max_connections = 20
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 13107kB
maintenance_work_mem = 64MB
min_wal_size = 1GB
max_wal_size = 2GB
checkpoint_completion_target = 0.7
wal_buffers = 7864kB
default_statistics_target = 100
sidekiqの統計もmuninにつっこめるようにプラグイン書いた。Docker構成なのでHTTP API経由でデータ取得するやつ https://mastodon.juggler.jp/media/lnNO3YPhIHzPMvpXFj0
まだsidekiqのジョブが120kくらい残ってますが、徐々に減っていってるのでそのうち改善します
対策なさそうなんで件のアカウントをサスペンドした。sidekiqのpushキューに膨大なジョブが積まれる
今朝悩んでた例ではなぜかプライマリキーをインデクスに使ってて、これは pg_class.relpages が statuses_pkey の方が小さいからだと思ってる
このアカウントは、notestockで公開設定になっていません。
＞ （テーブル全体の行のうち、数パーセント以上を占める）頻出値を検索する問い合わせでは、いかなる場合でもインデックスを使用しないため、インデックスにそれらの行を持ち続けることは全く意味がありません。
とんでもないこと書いてあるな…
(ローカル向け)不具合解決のために裏で試行錯誤してて応答悪い感じになってました。すいません
ALTER TABLE statuses ALTER COLUMN account_id SET STATISTICS 10000;
ANALYZE VERBOSE statuses (account_id);
を試してみたけど効果はなかった。
インデックスの選択が悪いということなので、 VACUUM ANALYZE を試してみるよ。時間かかりそう
その人が悪いことをしたという訳ではないのだけど、解決方法が見つからない場合はbanしてデータを消すしかなさそう。
特定アカウントのステータスが、リモートから来たのを含めた全ステータスの8%を占めるようになると、アカウント別のインデクスを使わずにstatuses_pkeyインデクスが使われる場合があるらしい。。。
ちなみにアカウント別ステータス数の１位がその人で 272804 、2位はリモートの人で 175731 です。2位以下は特に問題おきてません。
どうしようこれ。PostgreSQLには特定インデクスを強制使用させる方法が（追加でなにかインストールしない限り)存在しないんだよな…
だめだ、分からない… @fn_aki @unarist
https://gist.github.com/tateisu/390eaf6a4abc84a8c339677691638316 このスロークエリの対策を何か思いつきませんでしょうか…？
なるほどユーザによってはたまに遅くなるんだな。ID特定してからクエリ最適化しよう
https://mastodon.juggler.jp/media/Q2Sp5MHeqDJuZUYZrfo
これはなんで遅いのか分からない。
SELECT "statuses"."id", "statuses"."updated_at" FROM "statuses"
WHERE "statuses"."account_id" = 1 AND "statuses"."visibility" IN (0, 1) AND (
statuses.reply = false OR statuses.in_reply_to_account_id = statuses.account_id
) ORDER BY "statuses"."id" DESC LIMIT 40
とか試しに Analyzeしてみても私のIDだと1.324 msしか使ってない。
4000msかかってたクエリが0.6msになるんだから、元のは相当アレだったんだな…