Ruby1.8.6からRubyEnterprise1.8.7 p334にアップグレードすると、メモリサイズがほぼ2倍になります。これは、アップグレードした5台のFedora8サーバーのすべてで発生しました。Rails1.2.6をPassenger3.0.4で実行します。
Muninは、からvsz列とrsz列を合計することにより、すべてのプロセスのメモリサイズを取得します$ ps axo pid,comm,pmem,vsz,rsz。（仮想メモリサイズと常駐メモリサイズはどちらも同じ量だけ増加します）
これらの列は通常、プロセスで実際に使用されるメモリの量を誇張していることを認識していますが、これを使用して1.8.6、次に1.8.7 REEを測定した場合、それらは等しく肥大化するはずであり、したがって比較可能です。
さらに、マシンのコミットされたメモリ（/ proc / memstatにリストされている）が定期的にオーバーコミットされています。これは新しいことです。コミットされたメモリの量が大幅に増加し、現在スワップスペースに入っているようです。
ガベージコレクションはまだ調整していませんが、それが全体的なメモリフットプリントにどのように影響するかはわかりません。
Phusion FAQで推奨されているように、GC.copy_on_write_friendly変数をオンにしました。
この100％のメモリ使用量の増加の説明は何ですか？どうすれば修正できますか？修正方法、またはさらに優れた監視/デバッグ方法に関するアイデアをいただければ幸いです。
ありがとう。
- -アップデート
パフォーマンスを確認するために、1台のサーバーで実行中のインスタンスの数（PassengerMaxPoolSize）を12から10に減らしました。もう1つは、PassengerPoolIdleTimeを15分に引き上げました。コントロールとして使用されている3分の1があります。
非エンタープライズバージョン1.8.7p334をサーバーに配置して、1.8.7かEnterpriseEditionかを確認することを検討しています。
他の誰かがこのタイプの問題の経験がありますか？
個々のRailsプロセスを見ると、passenger-memory-statsで示されているように、1.8.6ではプロセスあたり約120MB、REE1.8.7ではプロセスあたり175MBです。
---アップデート2
REE 1.8.7と比較するために、MRI1.8.7をサーバーに配置しました。結果はさらに悪化し、メモリ常駐サイズ数と乗客メモリ統計が高くなりました。もちろん、スワッピングが始まりました。
これにより、1.8.7の方が1.8.6よりもフットプリントが大きいと私は信じています。
---アップデート3
サーバーにMRI1.8.7を配置しましたが、メモリ使用量の点でMRI 1.8.6よりもはるかに悪かったので、すぐにMRI1.86に戻りました。
私は、passenger-memory-statsにリストされているように、Railsプロセスサイズの平均を実行しました。REE1.8.7プロセスは73MB大きく、かなり大きいようです。
これは、同じメモリフットプリントに収まるように実行するプロセスを大幅に減らす必要があることを意味します。
より少ないプロセスでどのように機能するかを確認します。GCチューニングも始めています。
---アップデート4
Ruby1.8.7はRails1.2.6をサポートしていないようです。1.8.7の最初の公式にサポートされているバージョンはRails2.1です。アップグレード後に、それが問題の原因であるかどうかがわかります。