AmazonEC2フリーティアインスタンスは1つしかありません。 2つのDjangoサイトをホストしており、現在トラフィックはほとんどなく、1日あたりのリクエスト数はわずかです。サーバーはmod_wsgiを備えたApacheであり、Apacheは次のようにWSGIDaemonProcessで構成されています。
WSGIDaemonProcess mysite.com processes=4 threads=4 display-name=%{GROUP} user=djangoUser group=djangoUser python-path=/srv/mysite:/srv/mysite/venv/lib/python2.7/site-packages
WSGIProcessGroup mysite.com
2つのサイトのそれぞれについて。以前は、サイトは同じ構成とセットアップで問題なくlinodeでホストされていたので、問題が発生していることに少し驚いています。
サイトにアクセスするときに非常に頻繁に(50%以上の時間)、504 Gateway Time-out
を受け取り、アクセスの試行がApacheエラーまたはアクセスログにまったく登録されないため、デバッグが困難です。
弾性負荷分散について説明している同様のスレッドをここで見ましたが、それは私の場合ではありません。ルーティングして問題を解決する方法がわかりません。
これは、リクエストが行われたときの特定の時点でのトップの任意のスクリーンショットです。
[〜#〜]編集[〜#〜]
私は最終的に、これが誤って構成されたfail2ban
スクリプトであり、自分のIPをiptablesブラックリストに有限時間追加したことに気付きました。私の最初のリクエストは機能しますが、その後のリクエストは制限時間が切れるまでiptablesによってブロックされ、504が先行します。
EC2 t2.microインスタンスは恐ろしいです。そこで、私はそれを言いました。恐ろしい。非対話型アプリケーションを実行していて、特定のジョブの実行に必要な時間の10倍の時間がかかってもかまわない場合は、t2.microsで問題なく動作します。ただし、どのタイプのインタラクティブWebアプリケーションでも、価値はありません。
私の推測では、これが発生している期間中にtop
を見ると、CPUの盗難やiowaitの割合が高くなると思います。残念ながら、これを修正するためにできることは、より大きなインスタンスにアップグレードすることだけです。
AWSで利用できるより高度な機能が必要ない場合、1ドルあたりのパフォーマンスに関する限り、これは優れたソリューションではありません。 Linode、DO、およびその他のVPSプロバイダーは、同様のサイズのEC2インスタンスを簡単に上回ります。