【rails】メモリ断片化の対処法を知りたい

Question

• AWS EC2上で、railsをpumaで本番稼働しています。

• EC2はauto scalingで2つのインスタンスを起動しており、ユーザーがドメイン(例: https://abc.jp)にアクセスするとそのインスタンスのうちどちらかにアクセスが割り振られます。

• 一定時間経つと（約3日ぐらい）メモリがいっぱいになってOOMキラーが動き、railsが落ちるので、OOMキラーが動いたタイミングで

/etc/sysctl.confの設定でインスタンスが再起動するようにしています。

• ユーザーがサイトを訪問して、ページ内のフォームに入力後、送信ボタンを押した瞬間にメモリがいっぱいになり、OOMキラーが動いた場合、ユーザーが入力した内容はもう1つのインスタンスに渡されて、ページは表示されるのでしょうか？

なにぶん経験が浅く、railsをauto scalingで稼働させるには、普通どうやるのかの方法をよく分かっておりません

• ユーザーがアクセス中にOOMキラーが起こった場合は、フォームに入力していた内容はどうなるのか。どうすれば入力の送信完了まで担保できるのか

• こういった時はどう対処するのが普通なのか

• puma_worker_killer

というのは、READMEを読む限り使わない方がいいように見えるが、実際はどうなのか

を教えていただきたいです。

よろしくお願いします。

参考サイト： https://jp.quora.com/purodakushon-no-Rails-sa-ba-no-riyou-memori-ga-hitasura-zouka-shi-tei-ku-you-na-kyodou-wo-kansoku-shita-toki-dou-taiou-suru-no-ga-yoi-desu-ka

Answer 1

いっそ、OOMキラーを待つのではなく、OOMで落ちないうちにサーバを再起動（あるいはオートスケールを使って再構築）させてしまってはどうでしょうか？

ユーザーのアクセスがあったところでOOMを喰らえばデータの損失も起きえますが、管理しての再起動や再作成ならば、「終了予定のサーバには新規接続しないようにする→接続がなくなったところでサーバ破棄」のようにできます。

（なお、両サーバでセッションを共有できる形で管理するのが前提です）

Comments

[sdk]

ありがとうございます。
あれからとりあえず原因がメモリリークなのか、断片化なのかを特定しようと思ってcloudwatchで観察してます。
同時にインスタンスのメモリを1G -> 2Gに増やしたんですが、それから1度も落ちなくなりました。メモリ使用率がずっと横這いです。
単にメモリが少なすぎたのかと考えてしばらく静観することにしました。
いつもご回答ありがとうございます。