TomcatにデプロイされているJavaベースのWebアプリケーション(Grails))のパフォーマンステストを行っています。サーバーでは、次のサービスが実行されています。
理想的な世界では、これらのサービスは3つの別々のサーバーで実行されることを理解していますが、アプリケーションが負荷に対してどのように動作するかを確認したいだけです。 20
秒を超えるランプアップ期間で40
スレッドを実行すると、サーバーが応答しなくなるように見えることがわかりました。ただし、サーバーが応答しなくなる原因を正確に特定することはできません
当時はSSHで接続されていましたが、応答しなくなると、マシンにSSHで接続することすらできなくなります。これは、TOPが応答しなくなり、SSHで接続することさえできない場合のTOPからのデータです。なぜ応答しなくなるのかを示唆しているようには見えません。
質問
私が最初にすることは、これらのプロセスのいずれかがOSよりも多くのCPUまたはディスクを消費する可能性を減らすことですIO時間。あなたのOSはLinuxであると仮定します。
設定ファイルを編集する前に必ずバックアップしてください。
Sarデータを確認することで、クラッシュ直前のOSの動作に関するヒントを得ることができる場合があります。
sar -A | more
メモリまたはCPU使用率の上昇を必ず探してください。 /etc/cron.d/sysstatがインストールされて有効になっていると仮定して編集することで、sarをより頻繁に実行できます。
プロセスが実行されているサービスアカウントごとに、ファイルの最後にある/etc/security/limits.confに以下を追加できます。
Apache soft priority 19
Apache hard priority 19
rabbitmq soft priority 18
rabbitmq hard priority 18
mysql soft priority 10
mysql hard priority 10
次に、デーモンの各initスクリプトで、CPUを減らし、デーモンに割り当てられる時間をIO時間にします。
cp -p /etc/rc.d/init.d/some_init_script ~/`date '+%Y%m%d.%H%M'`.some_init_script
vi /etc/rc.d/init.d/some_init_script
スクリプトの2行目に次を追加して、CPUとIOタイムスライスを削減します。
renice 19 -p $$ > /dev/null 2>&1
ionice -c3 -p $$ > /dev/null 2>&1
各サービスを再起動します。
Sshdがまだ応答しなくなると仮定しましょう。 「screen」をインストールすると、vmstat、iotop、その他のツールをさまざまな画面で実行できます。画面の使用にはチートシートがありますので、ここでは取り上げません。
この時点で、サービスが制御不能になった場合でも、パニックを引き起こしていないと想定して、サーバーにSSH接続する機能が必要です。
特定のコアまたはCPUに固定することで、各デーモンに割り当てられるリソースをさらに制限できます。これは、コマンド「taskset」で実行できます。 その使用法の詳細についてはmanタスクセット。
[編集]これは特定のスピンロック条件下では役に立たないことも付け加えておきます。上記が役に立たない場合は、アプリケーションをVMで実行し、デバッグカーネルまたは他のデバッグツールを使用する必要があります。