サイト管理者EC2がたまにハングするようになる。2022/03/31wordpress環境を構築してから。インストールする際にストレージ容量とか気をつけてて、問題なさそうだったのに。対策1:スワップするようにしてみる。■対策2:s3のマウントをやめる。調査1頻度は1~2日に1回。AWSのモニタリングからわかるのはCPUの利用率が100%に張り付きその後、ステータスチェックの失敗が1になり、30分ごとにバックアップのためのネットワークアクセスがなくなる。sshでもログインできない。(※最初に起きたときはギリギリ生きていてsshは激重だった。)EC2のモニタリングのログ調査CPU利用率が100%に張り付き、その後CPUクレジットを使い切ってCPU利用率が0になり、そのままハングしている。CPUクレジットを使い切ってない間はsshできて辛うじて動いていたのであろう。Linuxのシステムログ調査システムのログにそれらしい記録ありシステムのログ/var/log/syslogを見てみた。OSがハングしてダンプしているログがある。Linuxのハングの分析は初めてだが、面白い。Memory、[systemd]がメモリ不足を回避するためにキルするプロセスを選んでキルしたというログらしい。何かが暴走して、CPUとメモリを無限に確保した後、システムが復旧しようとしたログなのであろう。キルされたのはマイクラサーバー、確かにoom-killerのプロセスのログから一番メモリをくってそう。その直前当たりを見てみる。定期的に動いているのはほとんどcronで動いているログのよう。output)→メールの設定ができていときに出るログ。設定できていればエラー内容をメールするらしい。バックアップスクリプトのどこかがエラーになっているのだろうか?ハングする前も出ているのでハングとは無関係そう。→こちらはwordpressのためにインストールしたphpの掃除?phpのインストール時に止まったのでPHP関連は怪しいが、ログからは成功していそう。reached↑派手にエラーが出ている。このエラーがきっかけでハングしたのか?ネットワークのタイムアウトっぽいが、他事が原因である可能性もある。そのままapt系が死んでいるのだろうと推定する。確かに、aptでPHPをインストールするときに途中で止まった。これが原因か?ダンプの最後の方で—メモリ不足でマイクラサーバーがキルされている。oom_score_adj:0その後いろいろ停止させられているログその後、cronのマイクラバックアップとPHP掃除のログが定期的に出る。完全には死んでなさそう。aptの日々更新も成功している。■rsyslogの設定cronのログを記録するように変更cronのマイクラバックアップがスクリプトがエラーを出しているような感じなのでcronのログを探したが、ない。ubuntuではデフォルトでcronのログがオフになっているらしく、設定を変えて記録してみる。rsyslogログは/var/log/cronログが出るようになったがsyslogと同じ内容のログしかでてない。Killerがそのプロセスを停止させた可能性があります。何らかの要因でメモリ不足になってイッちゃっているってのは間違いなさそう。■topコマンドでメモリ順メモリ不足ということで、とりあえずメモリを使ってそうなプロセスを確認したい。topコマンドで見れる。topコマンドはリアルタイムで更新してプロセスの情報を表示してくれる。下記ショートカットでソートできるみたい。これはメモっておく価値大。CPU使用率順にソート(デフォルト)■psコマンドでメモリ順オーソドックスなpsコマンドでもソートできるらしい。-n30-%menのところはpsコマンドの最初の行の項目名を入れればそれでソートしてくれるみたい。出力結果をエクセルにコピペ。ダンプ時のrssの単位が良くわからないので、dumpのところのrssとtopコマンドのRSSとの比率を出してみて考察。multipathd結果、普段からマイクラサーバーがメモリを140M、これは1番食っている。異常時は更に他のと相対的にみると異常に食っている気がする。次に多いのがs3fs、AWSのS3をマウントするコマンド。120Mも食っている。■マイクラサーバーはログインするとメモリ33%くらいになる。60■実際にメモリ不足?ログからは最後にoom起動=メモリ不足となっていることからもしかしたら、夜中に色々なのが同時に動いた際に実際にメモリ不足になっているかもubuntuのデフォルトはスワップが0らしい。0...スワップしていない対策1:スワップするようにしてみる。■スワップするようにしてみる。暫定になるかもしれないが、これで死ななくなればメモリが足りてない。これでも死ぬなら暴走していてメモリがいくらあっても無駄。このときサーバー再構築しよう。メモリの1.5倍程度sleepするときに全メモリをハイバネーションして退避するための量らしい。今時、メモリの量が莫大なものがあるので、例えば64Gのメモリのために64Gのストレージで退避させるのは時間がかかりすぎてアホらしいみたい。メモリが潤沢になった今は、今はスワップしない、sleepしないのが普通なのか。サーバーなので今までどおりはいハイバネーションしなくてよいが、それは別の設定かな?私のEC2のスワップサイズメモリサイズは1Gストレージの残容量は3G/8Gストレージの容量も最小で行きたいので、スワップサイズは1Gとする。方法はAmazonの説明で十分わかる。https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-memory-swap-file/1.スワップファイルを1G作成する。ブロックのサイズが128Mなのかはわからないが例にしたがう。MB/sちょっと時間がかかる。2.スワップファイルの読み書きのアクセス許可を更新する。UUID=6c93a3d7-008d-49be-b566-926ac00bc892スワップ領域にスワップファイルを追加して、スワップファイルを即座に使用できるようにする。/swapfile手順が正常に完了したことを確認します。-2早速、swapしている。ファイルを編集して、起動時にスワップファイルを起動します。エディタでファイルを開きます。/etc/fstabファイルの末尾に次の新しい行を追加し、ファイルを保存して終了。/81%使っていて残り、1.5G。wordpress運用しだしたら1年持つかくらいのギリだな。aptをトリガーにet0が死んでoom-killerが発動、bedrock_serverがkillされている。snapdはその後SIGABRTしている。snapdがSIGABRTしている。snapdがSIGABRTしている。aptをトリガーにet0が死んでoom-killerは動いていない。■snapdが怪しい。SDKherokuVSCodeおそらく、mariaDBを入れたときに入った?→違うっぽい。snapdamazonの何かを入れるときにはいったか?デフォルトで入っているのか?■対策2:s3のマウントをやめる。s3のマウントが思いの外、メモリを食っている。cliのインストールここを参考にした。S3とそのアクセス設定やらは以前やっているので、インストールと認証の設定のみ。https://qiita.com/uhooi/items/e915873ddabdf6e27fd72.マイクラバックアップスクリプトの変更S3をマウントして通常のディレクトリとしてマイクラのバックアップを普通にmvとかしていたのをaws-cliのコマンドに置き換える。ago’.tar.gz———-確認1.まず直接実行してバックアップファイルがS3にできることを確認。対応する1日前のファイルが無いので古いのを消す確認はできない。s3://minecraft-nyanpu/worlds_backup/mc_backup_hourly_20220401-174300*.tar.gz￼ブロックを追加メッセージからはうまく言ってそう。確認2.cronの時間が来たので動いたか確認。mc_backup_hourly_20220402-180000.tar.gz新しいバックアップはできた。〜20220402-180000.tar.gzただし、1日前のを消しているつもりが消えてない。〜20220401-180000.tar.gzが残っている。・もう1回、シェル上で直接実行したときのログを見る。あぁ!s3のファイルにワイルドカードは使えないのか!ワイルドカードにしないとタイムラグが怖かったんだよね。保存するときに”%H%M00′′と必ず00秒としたからよい。あれ?そうしてて、ワイルドカードが残りっぱなしなだけじゃん。*を消したら良いでしょう。start11%=110Mbyteくらいメモリを使っていた。結局メモリ不足スワップ領域を1G追加して、メモリを食ってた必須ではないs3のマウントをやめることで1〜2回/日発生していたハングはすっかりなくなった。結論はwordpress環境構築でのメモリ不足である。実際のトリガーはsnapdの日々更新。これで多分、普段、40%くらいしか食ってないメモリを食い尽くしたのであろう。他の対策としてこのメモリ大食いのsnapdを止めるか?止めるとセキュリティバージョンアップが働かないから危ういか?これからの運用でまた判断していこう。今回は勉強になったし、楽しかった。コメントをキャンセルメールアドレスが公開されることはありません。※サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。