https://twitter.com/kasu1923/status/1258721302690459648 はぁ可愛い
加齢により背中が曲がり始めたので、GW前あたりからコツアーチとかスッキリングとかの背中に敷くストレッチ器具を使い始めた。効くわ。１日一度は使いたくなる
IPX7防水の左右分離イアホン https://a-g-japan.com/tws04k を風呂用にポチった。finalの音響チームが音質を完全監修
中国で余った低品質マスクが日本で色んな売られ方をしてるけど、買った後でサポートを期待できないような店では買わん方がええよ
エアコンは届いたが設置工事業者に連絡がつかない…
またスマホの壁紙に動画を設定するなど
ジェネリックメソッドの戻り値を T? と書けないC#8.0かっこ悪い https://gist.github.com/tateisu/1af488861ea0272f7111e2e7736b9c0b
AMDの決算説明会でのコメント https://g-pc.info/archives/15495/
CometLake-s の価格 https://g-pc.info/archives/15327/
前者を見た後に後者を見ても全く安いと思わんな…。おまけに数年後MeteorLakeが出るころにはAMDはもっとプロセスの微細化を進めてる見通しだ
うちだとsidekiqの並行数を上げられない主な理由はRAMなのです。各jobの処理時間の大半はHTTPリクエストの応答待ちで、CPUもDBもボトルネックではない。
@noellabo sidekiqのメモリが増える要因はActiveRecordのキャッシュが大きいと思ってるのでプロセスを小分けにするとそれぞれキャッシュを持つ分だけ損かと思ってたんですが、メモリ多めのマシンだと分けた方が有利なのかもですねー。
@noellabo キューごとにプロセスを分けるのは割と必須ですね。何度かまとめようとはしましたが、すると何かのタイミングで事故が起きて元に戻す…を繰り返すだけでした。ここからは削りようがないのだと思います。
tootctl email_domains block を追加するPR。 https://github.com/tootsuite/mastodon/pull/13589 docker環境で実装するもんじゃないな…
俺は無法地帯を提供したい訳ではないし、外部から何かクレームが来た時に連絡先が不明なアカウントを抱えたい訳でもない
sute.jpの使い捨てメアドを使ったユーザは数人いたけど大半が投稿数0、一部投稿数20以内、いずれにせよもう使ってない人ばかりだったので気兼ねなくアカウント停止した
ついでにメールブロックドメインされたメールアドレスを使ってるユーザの一覧。 select accounts.username from users left join accounts on users.account_id=accounts.id
where exists( select 1 from email_domain_blocks where domain = substring(email from position('@' in email)+1) )
and accounts.suspended_at is null;
This account is not set to public on notestock.
スパムとは関係ないと思うけど sute.jp もブロックした。24時間で使えなくなるメールアドレスとか出されても連絡できないのだから困る
select * from (
select distinct * from (
select substring(email from position('@' in email)+1) as h
from users left join accounts on users.account_id=accounts.id
where accounts.suspended_at is not null
) as blocked order by h
) as sorted where not exists( select 1 from email_domain_blocks where domain = h );
サスペンド済みローカルユーザのメールアドレスのドメイン部分がまだメールアドレスブラックリストに登録してないやつを一覧するクエリ
This account is not set to public on notestock.
@noellabo キューが優先度別になってても、低優先のjobを中断してまで高優先のjobを処理してくれる訳ではないです。プロセス内の並行数がいちど低優先のjobで溢れると、同プロセス内の高優先キューの処理が著しく遅くなります。この問題はキューごとにプロセスを分ける事でしか解決策できません。defaultは死守しないとWebUIの応答性が悪くなるので専用のプロセスを立てる。pullはフォローリクエストで溢れるので専用のプロセスを立てる。mailとpushは残りの1プロセスにする。という3プロセス構成が負荷対策の基本だと思います。
