Tomcat7でWebアプリケーションが非常に遅い
Tomcatサービスを開始するためのWebアプリケーションを実装しましたが、非常に迅速に機能しますが、何時間も費やし、より多くのユーザーが入ると遅くなります（最大約15ユーザー）。
チェックRAM使用統計（20％）、CPU（25％）
サーバーの機能：
- RAM 8GB
- プロセッサーi7
- Windows Server 200864ビット
- Tomcat 7
- MySql 5.0
- Struts2
- -Xms1024m
- -Xmx1024m
- PermGen = 1024
- MaxPernGen = 1024
私はWebサーバーを使用していません。Tomcatで直接公開しています。
真夜中の遅さの入力は引き続き維持されます（オンラインのユーザーは1人のみ）
私が持っている解決策はTomcatサービスを再起動することであり、応答時間は再び優れています。
この問題を経験した人はいますか？手がかりをいただければ幸いです。
十分な詳細が提供されていません。詳細情報が必要です:(
htopまたはtopを使用して、プロセスごとおよびスレッドごとのメモリとCPUの使用量を検索します。
CPU
4コアシステムで一定の25％のCPU使用率は、シングルコアアプリケーション/スレッドが使用できる唯一のコアで100％のCPUを実行していることを示している可能性があります。
どのアプリケーションがCPUを消費していますか？
記憶
20％のメモリは約1.6GBです。これは、Tomcat + mysqlのみを実行しているアイドル状態のサーバーに期待するよりも少し多いです。 -Xms1024は、Tomcatに1GBのメモリを事前に割り当てるように指示します。
Tomcatの設定を-Xms512および-Xmx2048に変更します。一部のユーザーをTomcatにスローしている間、Tomcatのメモリ使用量を監視します。 2GBに達するまで成長し続ける場合...その後フリーズする場合は、メモリリークを示している可能性があります。
ディスク
df -hを使用してディスク使用量を確認します。完全なパーティションは、発生している問題を引き起こす可能性があります。
Filesystem Size Used Avail Usage% Mounted on
/cygdrive/c 149G 149G 414M 100% /
（この例で、私のラップトップの容量が不足していることを発見した場合。正しく実行しています：D）
ログ
ログは素晴らしいです。それでも、彼らはディスクをいっぱいにする悪い習慣を持っています。ログのディスク使用量を確認します。新しいユーザーが接続したときに、ログは適切に書き込まれ、消去され、回転されますか？ログを消去すると問題は解決しますか？ （消去する前に、将来の分析のためにどこかにコピーしてください）
そうでない場合。ログはまだ素晴らしいです。彼らはあなたがバグを追跡するのを助ける良い習慣を持っています。 Tomcatログを確認します。デバッグするログレベルを設定することをお勧めします。ウェブサイトが死んだときに最後に何が起こりますか？有用なエラーメッセージはありますか？ユーザー接続は引き続きTomcatによって受信および受け入れられますか？
応用
私は25％のCPUが（mysqlではなく）Tomcatに行くと思います。 Tomcatはそれ自体では失敗しません。その上で実行されているアプリケーションは失敗している必要があります。アプリケーションをTomcatから削除してみてください（最終的には代わりにhello worldを配置できます）。 Tomcatはアプリケーションなしで一晩動作し続けることができますか？おそらく可能ですが、その場合、障害はアプリケーションにあります。
アプリケーションで完全なデバッグログを有効にして、問題の追跡を試みてください。 Eclipseから直接デバッグモードで実行し、ユーザーをスローします。同じように一貫して失敗しますか？
はいの場合は、Eclipseデバッガーで「一時停止」を押して、アプリケーションの動作を確認します。各スレッドが現在実行しているコードとその呼び出しスタックを見てください。それを数回繰り返します。デッドロックや無限ループなどがある場合は、この方法で見つけることができます。
運が良ければ、この問題はもう見つかります。そうでない場合は、残念ながら、アプリケーションの奥深くにある可能性のあるトリッキーなバグです。それを追跡するのは難しい場合があります。決意は成功につながります。頑張って=）
パフォーマンス関連の問題については、次のルールに従う必要があります。
- 効果を上げるために、xmsとxmxのサイズを均等化して強調することができます。
-Xms2048m -Xmx2048m
- PermGenをガベージコレクションできるようにすることもできます。
-XX：+ UseConcMarkSweepGC -XX：+ CMSPermGenSweepingEnabled -XX：+ CMSClassUnloadingEnabled
ページが頻繁に変更されてこのオプションを論理的にできない場合は、動的コンテンツを一時的にキャッシュしてみてください。そうすれば、ページを何度も再生成する必要がなくなります。再度実行するのではなく、すでに実行された作業をキャッシュするために使用できるすべての手法を使用する必要があります。これは、Tomcatの最高のパフォーマンスを達成するための鍵です。
データベース関連の問題がある場合は、次のようにすることができます sql query perfomance Tuning
Catalina.outログファイル
without restarting Tomcatをローテーションします。
詳細には、2つの方法があります。
最初のは、より直接的ですが、Catalinaのスタートアップで選択したログローテーションツールに単純なパイプを追加することで、Catalina.outを回転させることができます。シェルスクリプト。これは次のようになります。
"$CATALINA_BASE"/logs/catalina.out WeaponOfChoice 2>&1 &
"WeaponOfChoice"をお気に入りのログローテーションツールに置き換えるだけです。
2番目の方法は直接的ではありませんが、最終的には優れています。 Catalina.outの回転を処理する最良の方法は、回転する必要がないことを確認することです。 "server.xml"のすべてのコンテキストで「swallowOutput」プロパティをtrueに設定するだけです。
これにより、System.errとSystem.outが、構成したロギング実装にルーティングされます。構成していない場合は、JULIにルーティングされます。
- 詳細については、次を参照してください： Tomcat Catalina Out
Centos7のクリーンインストールで非常に遅いストックTomcatダッシュボードを経験し、次の原因と解決策を見つけました。
Tomcatの起動時間が遅いのは、多くの場合、JavaのSecureRandomの実装に関連しています。デフォルトでは、エントロピーソースとして/ dev/randomを使用します。システムイベントを使用してエントロピーを収集するため、これは遅くなる可能性があります（ディスクの読み取り、キーの押下など）。 urandomのマンページが述べているように：
When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
次の構成オプションをTomcat.confまたは（推奨）カスタムファイルに/Tomcat/conf/conf.d/に追加して修正します。
Java_OPTS="-Djava.security.egd=file:/dev/./urandom"
同様の問題が発生しました。原因は「catalina.out」でした。これは、「System.out」および「System.err」の標準の宛先ログファイルです。サイズが大きくなり続けるため、処理速度が低下し、最終的にTomcatがクラッシュしました。この問題は、「catalina.out」を回転させることで解決されました。 redhatを使用していたので、「catalina.out」を回転させるシェルスクリプトを作成しました。
ここにいくつかのリンクがあります：-
カタリナに関するMulesoftの記事（回転する2つの方法も含まれています）：
「catalina.out」が問題ではない場合は、代わりにこれを試してください：-
Tomcatの最適化に関するMulesoftの記事： Tomcatのパフォーマンスを最適な速度に調整する
私たちはあなたと同じように見える問題を抱えていました。 Tomcatの応答は遅かったが、アクセスログには応答が数ミリ秒しか表示されなかった。問題はストリーミング応答でした。当社のサービスの1つは、ユーザーがサブスクライブできるリアルタイムデータを返しました。 EPOLLは肥大化していた。ネットワーク要求がTomcatに到達できませんでした。さらに興味深いことに、CPUはほとんどアイドル状態であり（サーバーに何もするように要求できなかったため）、アクセプター/ポーラースレッドはWAITやIN_NATIVEではなくRUNNINGにありました。
当時、私たちはそのようなリクエストの量を制限しただけで、すべてが正常になりました。