{進捗記録}{希哲10年}{進捗}{デライト}{23時}{18時}{17時30分}{壊衝}{違了}{出振るい}(81)

{希哲15年10月1日9歩 K#F85E/E74C-3682}

障害対応まとめ

最近安定していたデライトが今日に限って妙に壊衝しているなと思い,17時30分頃から本腰を入れ調査開始

ここのところ出振るいしていないため実装の問題とは考えにくく,出力録を見ても違了痕跡が無いため,deln_tmo.cron誤作動であることはすぐに見当が付いた出力録譜類を見ると,昨日30日ちょうど23時から譜類激増していたため,何らかの期限による問題であると気付いた

試しに wget実行してみると,SSL 証明書検証失敗していた。有効期限はまだ少し先だが,調べてみるLet's Encryptルート証明書に関する問題で,以前から警告されていたらしい。

18時前,いったん –no-check-certificate を付けて対処した。似たような問題将来的にも起こりうるので,根本的な改善策見つけたい

今後,「古い環境」に Let's Encrypt 自体が正式には対応しなくなるという話だが,その古さというのが希哲10(2016)以前とのこと。もともとデライト古い舞覧への対応手が回っていないため,実質的な非対応舞覧に近く,大きな影響は無いだろう。

今後,対応舞覧を広げる時に Let's Encrypt採用継続検討することにした。


どうも1分間隔落とされては0.1秒後に再起動するということを繰り返していたようだ。違了処理輪郭選り手抜控機能おかげもあり致命的な問題にはならなかった。

さらに本腰を入れ調査開始してから30分ほどの解決で,ついこのあいだのデバッグ環境整備効果実感することも出来,障害対応良い経験になった。

{進捗記録}{進捗}{待滅}{手定め}{握接}{録監視}{中処器使用率}{希哲15年3月14日5歩}{気付いた}{deln_tmo.cron}(30)

{希哲15年3月14日6歩 K#F85E/E74C-A95B}

前歩での対策後,しばらくしてからまた待滅が発生(deln_tmo.cron手定め前だった)。

top で見ると,deln.fcgi中処器使用率がほぼ100%になっていた。

録監視してみると,Linguee Bot毎秒のように握接してくることに気付いた悪質なクローラーであることは認識していたが,月庭から持ってきた握接禁止設定からなぜか漏れていたため追加。

これも含めて雑多握接集中した時に立求が詰まっているようだ。

deln_tmo.cron の動作確認も済ませ,以後安定

{進捗記録}{進捗}{デライト}{10秒}{待滅}{気付いた}{deln_tmo.cron}{希哲15年3月14日の進捗時限}{希哲15年3月14日の進捗}{希哲15年3月14日}(28)

{希哲15年3月14日5歩 K#F85E/E74C-EE79}

安定稼動していたデライトも,ここ数週間ほどで少しずつ重さを感じる場面が出てきた。1週間ほど前からたまに待滅発生することに気付いたが,今日は間を置かず3回待滅に出会し,簡単な対策を講じた。

まず,10秒待ってウェブ捌きから応答が無ければ再起動するように deln_tmo.cron追加した。

さらに,ずっと30設定していた立求処理用のスレッド数100変更した。

これによって若干の体感速度向上が見られた。

{deln_tmo.cron}

{}