監視画面でみるとこんな感じです。
名前は「はん」です。handon.club管理人です。
発言数多いです。空中リプライを多用します。内輪投稿が多いですが,どなたでも気軽に話しかけてください。
全ての投稿は個人の見解であり,所属する組織やはんドンクラブを代表する見解ではありません。
★Admin of handon.club.
★Inquiry for handon.club / 運営への問い合わせ
ダイレクトメッセージ or highemerly me.com (
→ @ )
★Server info. / 運営情報
#handon_info or https://handon.hatenablog.jp/
その他は固定トゥート参照
★Patron / カンパ
https://fantia.jp/handon or https://www.amazon.jp/hz/wishlist/ls/2GFSVDC4FW72T
★Icon
@ech
■現状の時系列
22:46:30頃 web1サーバ CPU利用率高騰開始
22:46:45頃 HTTPレスポンス監視 警報発報
22:48:30頃 web2サーバ CPU利用率高騰開始
22:48:59 dbサーバ pbouncer 問題発生開始(DB,ユーザ名nullによるmax_client_conn)
22:49:04 web2サーバ rack_attack.rb によるAPI RateLimit 問題発生開始
22:49:15頃 web1サーバ CPU利用率警戒域(60%超)
22:51:50頃 web2サーバ CPU利用率警戒域(60%超)
22:55:19 web1サーバ rack_attack.rb によるAPI RateLimit 問題発生開始
23:34:35頃 HTTPレスポンス監視 警報解除
23:36:15頃 web1サーバ CPU利用率 定常レベルに改善を確認
23:38:15頃 web2サーバ CPU利用率 定常レベルに改善を確認
【障害復旧報】はんドンクラブサーバに非常に繋がりにくい事象が発生していましたが現在は回復しています。おそらくffmpegのバグです。詳細は明日ブログにまとめます。今日は眠いので寝ます。
〇発生日時: 2019/11/28 22:46〜23:34 (JST)
〇影響範囲: web,streamingサービスを利用していた一部ユーザ
〇影響内容: レスポンス低下
〇原因: 大容量の動画投稿による処理遅延
〇復旧方法: 動画エンコード完了後自動的に復旧
〇再発防止策: 検討中
This account is not set to public on notestock.
あなたはシステム管理者から通常の講習を受けたはずです。
これは通常、以下の3点に要約されます:
#1)他人のプライバシーを尊重すること。
#2)タイプする前に考えること。
#3)大いなる力には大いなる責任が伴うこと。
〇運営方針: https://handon.club/about/more
〇利用規約、プライバシーポリシー: https://handon.club/terms
〇稼働ステータス(自動): https://status.handon.club/
〇運営ブログ、障害情報周知(手動): https://handon.hatenablog.jp/
mastodonの dist/nginx.conf における client_max_body_sizeってなんで80Mなんでしょうか。 冷静に考えると,ちょっとでかすぎません?(そんなファイルを送りつけられてもffmpegでのエンコードが大変)(それが原因で昨日サーバ落とした)
どうせリサイズするしでかいファイルでも通しちゃえ,ってことなんだろうけど,ffmpegの処理負荷を考えると nginx で 20Mくらいでrejectしてもらった方がよい可能性はないだろうか。
@gomama オリジナルの定義が分からないけど,それを送りつけられてもサーバ側で保存するオリジナル画像がエンコードされるよ