悪い夢を見た。…とはいえ、いないものとして扱われるのは加齢すると普通によくあることなので、あまり影響はない。
人間の作品だと https://dic.pixiv.net/a/users%E5%85%A5%E3%82%8A によると 60万users入りが存在するらしいので、AI作品の人気はまだまだ低い、となる。
まあAIイラストへの反発が大きいというのはあるかもしれない。そもそも人間用の評価システムにAIガチャを混ぜるのは良くないという話もある。量産連投が反発されやすい。NovelAI のデフォルト作風のままで似通った印象の画像が多いのも評価されない要因。
試験的にウチで出してるのは1000を超えたのが１個あるだけで、だいたい100-400に収まる感じでした。
#Pixiv のAI関連タグのイラスト人気順トップのブクマ数。(AI画像を素材として使うとかNGなウマ娘エロ二次を除く)
3,335 #StableDiffusion
3,235 #NovelAI , #NovelAIDiffusion
2,393 #WaifuDiffusion
(タグを付けない #潜伏AI絵師 の画像は当然ですが含まれません)
https://gochisou.dev/@aquarla/105024325010298825 これはバージョン番号がついてからSTも対応したい。
フォロースパムだとサスペンドして回るしかないよなーってなる。しかたないね
どうも既存のアカウントがハックされてるっぽいので、アカウント作成日で絞り込むとかは出来ないっぽい。
スパム対策用スクリプト
https://gist.github.com/tateisu/eca5fcf595953ad50e8eba4358741f94 アカウントのプロフの"表"のに書かれたURLのホスト部分のIPアドレスが特定の値ならサスペンドします。大量のホスト名のDNS解決とか面倒くさいんじゃ…。 removeSpam2.pl --userDomain=mastodon.social 185.117.119.170 みたいに使う
mastodon4j は死んだんだ。いくら呼んでも帰っては来ないんだ。もうあの時間は終わって、君も人生と向き合う時なんだ
2匹のオスのマウスから子が誕生 http://blog.livedoor.jp/goldennews/archives/52053219.html 性別からより自由になれる、ってことで良いことなんじゃないだろうか
中国のビットコイン採掘者、鉄道網から盗電した罪で3年半の懲役 http://thebridge.jp/2018/10/bitcoin-mining-power-theft 暗号通貨の採掘は盗まれた電気で成り立ってる部分がかなりある。proof of workの暗黒面だ
@mayaeh /about と /about/more と WebUIの投稿欄 については、マスコットまたはデフォルト象が使われます。インスタンスのサムネイルが使われるというのは誤りですね
@mayaeh あ、マスコットじゃなくて「インスタンスサムネイルが使われるよ」という訳がおかしいんですね
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になるんだから、元のは相当アレだったんだな…
