リモートマシンから、Ubuntu VPSに対して100の同時リクエストを実行しました
ab -n 100 -c 100 http://...
そして、私が疑ったように、サーバーは「クラッシュ」しました。まだpingを実行できますが、非常に迅速に応答します(約50ミリ秒)。しかし、ssh
をそこに入れたり、Webサーバーにアクセスすることはできません。以前は10件の要求を同時に1000件実行しましたが、1秒あたり約80件の要求で迅速かつ確実に応答しました。
5分間早送りすると、ログインできます。Webサーバーは正常に動作し、すべてが再び完璧になります。
稼働時間から、load_averageは0.06, 0.04, 0.05
であり、空き容量(512MBのうち)が1/4ギガバイト残っていることがわかります。 netstat -n
を実行するとlots and lotsのような行が得られます:
tcp 0 0 127.0.0.1:9311 127.0.0.1:35030 TIME_WAIT
tcp 0 0 127.0.0.1:5984 127.0.0.1:54384 TIME_WAIT
tcp 0 0 127.0.0.1:9311 127.0.0.1:35024 TIME_WAIT
サーバーは、nginxをリバースプロキシとして実行しており、少数のcherrypyサーバーが背後にあります。これらのサーバーは8000〜9000のポートで実行され、127.0.0.1
のみをリッスンします。
これはホスティング会社が提供する絶対的な最小スペックのサーバーですが、100の同時リクエストはあまり思えません。サーバーがクラッシュしたときに何が起こったかを調査するにはどうすればよいですか?
サーバーはクラッシュ後に再起動しませんでした。 kern.log
にメッセージが書き込まれず、サーバーの前にファイアウォールがありません。
システムのパフォーマンスデータを記録するものをインストールし、これらのベンチマークを実行しながら実行する必要があります。 collectdはこのために非常に人気がありますが、事前に重い学習が必要になります。 「sysstat」をインストールして「sar」コマンドを取得できますが、粒度はわずか10分なので、すべての問題をキャッチできない可能性があります。また、5秒ごとにIO/load/memoryに関する統計を出力する 'vmstat 5'のようなものをログインして実行することもできます。
PHPでApacheプリフォーク(デフォルト)を使用している場合、小規模サーバーでは100です。リクエストを満たすには100の同時プロセスが必要になるためです。 MaxClientsを100未満に設定した場合、リクエストはキューにバックアップされ、非常に遅くなります。それはおそらく、システム全体のクラッシュよりも好ましいでしょう。