misskey-dev
ドライブが開かないユーザーがいる
💡 Summary
色々な条件が重なるとuserId, folderId, id のIndexが採用されず、idのPK Indexが採用された結果タイムアウトするらしい
具体的には、ドライブのレコード数が大量、直近の31件のファイルのアップロードがとても少ないことが条件っぽい？ limit 31 で31件集めるのにタイムアウトする模様
🥰 Expected Behavior
狙ったIndexが採用される
🤬 Actual Behavior
misskey@misskeydb ERROR: canceling statement due to statement timeout
2024-07-15 06:40:16.410 UTC [3609383] misskey@misskeydb statement:
select
"file"."id" as "file_id",
"file"."userId" as "file_userId",
"file".
"userHost" as "file_userHost",
"file"."md5" as "file_md5",
"file"."name" as "file_name",
"file"."type" as "file_type",
"file"."size" as "file_
size",
"file"."comment" as "file_comment",
"file"."blurhash" as "file_blurhash",
"file"."properties" as "file_properties",
"file"."storedInter
nal" as "file_storedInternal",
"file"."url" as "file_url",
"file"."thumbnailUrl" as "file_thumbnailUrl",
"file"."webpublicUrl" as "file_webpub
licUrl",
"file"."webpublicType" as "file_webpublicType",
"file"."accessKey" as "file_accessKey",
"file"."thumbnailAccessKey" as "file_thumbnai
lAccessKey",
"file"."webpublicAccessKey" as "file_webpublicAccessKey",
"file"."uri" as "file_uri",
"file"."src" as "file_src",
"file"."folderI
d" as "file_folderId",
"file"."isSensitive" as "file_isSensitive",
"file"."maybeSensitive" as "file_maybeSensitive",
"file"."maybePorn" as "fi
le_maybePorn",
"file"."isLink" as "file_isLink",
"file"."requestHeaders" as "file_requestHeaders",
"file"."requestIp" as "file_requestIp"
from
"drive_file" "file"
where
"file"."userId" = $1
and "file"."folderId" is null
order by
"file"."id" desc
limit 31
📝 Steps to Reproduce
explain
select
"file"."id" as "file_id",
"file"."userId" as "file_userId",
"file".
"userHost" as "file_userHost",
"file"."md5" as "file_md5",
"file"."name" as "file_name",
"file"."type" as "file_type",
"file"."size" as "file_size",
"file"."comment" as "file_comment",
"file"."blurhash" as "file_blurhash",
"file"."properties" as "file_properties",
"file"."storedInternal" as "file_storedInternal",
"file"."url" as "file_url",
"file"."thumbnailUrl" as "file_thumbnailUrl",
"file"."webpublicUrl" as "file_webpublicUrl",
"file"."webpublicType" as "file_webpublicType",
"file"."accessKey" as "file_accessKey",
"file"."thumbnailAccessKey" as "file_thumbnailAccessKey",
"file"."webpublicAccessKey" as "file_webpublicAccessKey",
"file"."uri" as "file_uri",
"file"."src" as "file_src",
"file"."folderId" as "file_folderId",
"file"."isSensitive" as "file_isSensitive",
"file"."maybeSensitive" as "file_maybeSensitive",
"file"."maybePorn" as "file_maybePorn",
"file"."isLink" as "file_isLink",
"file"."requestHeaders" as "file_requestHeaders",
"file"."requestIp" as "file_requestIp"
from
"drive_file" "file"
where
"file"."userId" = '9bcuu9u19o'
and "file"."folderId" is null
order by
"file"."id" desc
limit 31
Limit (cost=0.43..5562.96 rows=31 width=1806)
-> Index Scan Backward using "PK_43ddaaaf18c9e68029b7cbb032e" on drive_file file (cost=0.43..338238.08 rows=1885 width=1806)
Filter: (("folderId" IS NULL) AND (("userId")::text = '9bcuu9u19o'::text))
PK_43ddaaaf18c9e68029b7cbb032e
これがIndexとして採用されている
💻 Frontend Environment
* Model and OS of the device(s):
* Browser:
* Server URL:
* Misskey:
🛰 Backend Environment (for server admin)
https://misskey.systems/
* Installation Method or Hosting Service:
* Misskey: 2024.5.0 or later
* Node: v20.10.0
* PostgreSQL: PostgreSQL 15.7 (Ubuntu 15.7-1.pgdg22.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
* Redis:
* OS and Architecture:
MisskeySystems ~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
Do you want to address this bug yourself?
- [ ] Yes, I will patch the bug myself and send a pull request
具体的には、ドライブのレコード数が大量、直近の31件のファイルのアップロードがとても少ないことが条件っぽい？ limit 31 で31件集めるのにタイムアウトする模様
drive_fileは2176449 レコードある 対象ユーザーのドライブは1349件
直近のidはこれ（aidからタイムスタンプに戻すのめんど……）
9r5ejg4hha 9r5epghomv 9r5eqa3bn0 9r5es4iqnm 9r5f39i1sq 9r5f3rz6tg 9r5f7a3d0a 9r5f8x8e10 9r5fbm4j49 9r5ff7gv89 9r5fff1b8i 9r5fikj3ao 9r5fjyq9bj 9r5fk64dbk 9r5fmsfhgh 9r5fsrzul7 9r5fuqjtn4 9r5g4haj0w 9r5g52jc1c 9r5g7db932 9r5ga2al6m 9r5gajyg7r 9r5gdjbjd0 9r5ge8ppdo 9r5gf4fpf2 9r5gx0tu2k 9r5h5k60dq 9s1lo4k035 9s1ln6uw2w 9szbddkaab 9szbz1pyi7 9uktz7wanv 9ts2xala18 9tz3g1ydn2 9u3ma2nq2f 9u3mdikk7k 9v9abbjbzi 9v9b3gmu1t 9vaij5r6ox 9vaimb05rr 9vi620oumc 9vi623m5md 9vi63awyn6 9vi63clmn7 9vq799l17i
aidからタイムスタンプに戻すのめんど……
https://github.com/misskey-dev/misskey-hub-next/issues/206
同様の現象が kasei.skiでも発生していています。
発生しているのは1ユーザーで、そのユーザーのドライブをモデレーター権限で別の人が閲覧すると正常に閲覧できるのですが、DBではなくredisが何らかのクエリをキャッシュしているとかでしょうか…？
◽️Misskey側で対応されたらうれしいこと IS NULL になるwhere文はIndexがいつか効かなくなると思います folderIdもそうですが、hostがIS NULLなので爆発しがちの予感 NULL狙いのwhereはパフォーマンス的に問題がないという話とあるという話が両方インターネットで語られているのでよく精査する必要があります
◽️短期的な鯖缶の対応 その1 大量にあるレコードを減らすことで、検索が早くなります 現状、ドライブのテーブルはリモートからくる添付ファイルも全て格納されているので、想像よりもはるかにたくさんのレコードがあります (私のところではこのテーブルのなかで自分のサーバーのデータは1/10くらいでした)
これを削除すれば直りますが、これが消えているとノート側から画面上しれっと添付ファイルがないように見えるので微妙なとこです
◽️長期的鯖缶の対応 その2 パーティションを切れば私の予想では大丈夫なはずです 私は検討はしていますがまだやったことがありません
folderIdもそうですが、hostがIS NULLなので爆発しがちの予感
folderId IS NULL -> ルードフォルダである host IS NULL -> リモートではない
…であるという意味で使われているようなので、それぞれに対応する意味を持つbooleanなカラムを持たせ、上記条件をSQLで判定するときはそのカラムを使うようにするという手段が必要かもしれません…?（isRootとか、isLocalとか）
まだ検証できていないのですが… b-treeの仕組みを考えると、NULLをあてにするよりもNOT NULLなbooleanの方がindexのヒット率が上がると考えています（もっと楽にやる方法があればそれでも）
