SliceHostのRailsアプリの問題を交換します
-
10-10-2019 - |
質問
SliceHost(256M)でホストおよび実行されているRails 2.3.8アプリがあります。私はバックエンドにまったく馴染みがありません。基本的に、SliceHostチュートリアルのステップに従ってApacheをインストールしました。メモリの使用量は非常に高く、Apache confファイルを変更してmaxClient数を10に減らしました...しかし、私のスライスはまだスワッピングしています。
これが、私のサイトを数回クリックした後に私が得るメモリの使用法です。
top - 23:57:12 up 28 min, 2 users, load average: 0.43, 0.54, 0.30
Tasks: 79 total, 1 running, 78 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 97.8%id, 0.1%wa, 0.0%hi, 0.0%si, 2.0%st
Mem: 262364k total, 258656k used, 3708k free, 260k buffers
Swap: 524280k total, 262772k used, 261508k free, 6328k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4004 web-app 20 0 178m 72m 1888 S 0 28.4 0:04.38 ruby1.8
4001 web-app 20 0 172m 61m 1932 S 0 24.2 0:02.72 ruby1.8
3941 root 20 0 164m 57m 1672 S 0 22.5 0:21.44 ruby
3990 web-app 20 0 209m 21m 1696 S 0 8.4 0:18.00 ruby1.8
3950 web-app 20 0 165m 7464 1548 S 0 2.8 0:20.40 ruby1.8
3684 mysql 20 0 224m 6504 2084 S 0 2.5 0:14.34 mysqld
3938 root 20 0 53632 3048 1036 S 1 1.2 0:01.50 starling
3839 root 20 0 243m 1456 1248 S 0 0.6 0:00.34 apache2
3897 www-data 20 0 243m 1452 1072 S 0 0.6 0:00.04 apache2
3894 www-data 20 0 243m 1368 1008 S 0 0.5 0:00.04 apache2
3895 www-data 20 0 243m 1220 960 S 0 0.5 0:00.02 apache2
3888 root 20 0 46520 1204 1100 S 0 0.5 0:02.29 ruby1.8
3866 root 20 0 17648 1184 896 S 0 0.5 0:00.08 bash
3896 www-data 20 0 243m 1180 952 S 0 0.4 0:00.00 apache2
3964 www-data 20 0 243m 1164 956 S 0 0.4 0:00.02 apache2
3892 www-data 20 0 243m 1132 956 S 0 0.4 0:00.00 apache2
3948 www-data 20 0 243m 1132 956 S 0 0.4 0:00.00 apache2
3962 www-data 20 0 243m 1132 956 S 0 0.4 0:00.02 apache2
3963 www-data 20 0 243m 1132 956 S 0 0.4 0:00.00 apache2
3965 www-data 20 0 243m 1080 888 S 0 0.4 0:00.00 apache2
3887 root 20 0 89008 960 796 S 0 0.4 0:00.00 ApplicationPool
次に何をすべきかわかりません...より大きなスライスにアップグレードできますが、今のところはこのアプリにトラフィックがほとんどないので、構成やコードの問題だと思いますか?
具体的な推奨事項は大歓迎です!ありがとう
解決
Railsアプリは利用可能なすべてのメモリを使用しているようです。私は3つのことをお勧めします:
サーバーのメモリをアップグレードします。 256MBは、Railsアプリにはそれほど多くはありません。 512に行くと、問題が軽減される場合があります。それが解決した場合、パフォーマンスの問題を追跡するのにどれくらいの時間がかかるか(18ドル/月)を考慮する必要があります。
アプリケーションをプロファイリングして、どのリクエストが最もメモリを消費しているかを把握します。これは、多くのレコードを見つけて、おそらく関連するテーブルも含めている場所になる可能性があります。可能なトラブルエリアを絞り込むのに役立つツールがいくつかあります。私は使用しました oink しかし、間違いなく他の人がいます。問題がどこにあるかを把握したら、メモリの使用量を減らすためにいくつかの調整を行うことができます。
Apacheで乗客を使用していると仮定すると、乗客の構成ファイルの同時リクエストの数を減らすことができます。これはそれに役立つかもしれません https://serverfault.com/questions/15350/running-ruby-on-app-on-apache-passenger-to-muchmemory
他のヒント
要するに、256MBはRailsアプリケーションの場合はタイトです。あなたは本当にあなたがレールをどのように実行しているかについて実際には何も提供していませんでしたが、私はあなたが乗客モジュールでApacheを使用していると思います。乗客モジュールは、実行を続けるインスタンスの数で構成できます。 Web-Appアカウントの下で実行されている4つのRubyインスタンスがあります。それらは乗客から来ていると思います。構成では、乗客が起動するインスタンスの数を制限できます。これにより、メモリの要件が削減されます。
一方、256MBのみで作業し、1つのRailsアプリケーションのみをホストしている場合は、別のセットアップに行く方が良いかもしれません。私が以前に使用したセットアップは、Nginx Webサーバーと2つのMongrelsを備えたMongrelクラスター(192MBで、アプリケーションはテスト目的のみを目的としていました)でした。基本的に、それはいつでも一度に、2つ(および2のみ)のレールリクエストを並行して処理できることを意味します。セットアップはApache+乗客よりも少し難しいかもしれませんが、間違いなく難しくありません。 256MBに固執するとき、それはよりパフォーマンスのあるソリューションだと思います。