私はTomcatサービスを開始するためにWebアプリケーションを実装しましたが、非常に迅速に機能しますが、何時間も費やし、より多くのユーザーが入ると遅くなります（最大15ユーザー）。
RAM使用統計の確認（20％）、CPU（25％）
サーバーの機能：
私はWebサーバーを使用していません。Tomcatで直接公開しています。
真夜中の遅さの入力は引き続き維持されます（オンラインのユーザーは1人のみ）
私が持っている解決策はTomcatサービスを再起動することであり、応答時間は再び優れています。
この問題を経験した人はいますか？手がかりをいただければ幸いです。
十分な詳細が提供されていません。詳細情報が必要です:(
htopまたはを使用topして、プロセスごとおよびスレッドごとのメモリと CPU の使用量を確認します。
4 コア システムで一定の 25% の CPU 使用率は、シングルコア アプリケーション/スレッドが使用できる唯一のコアで 100% の CPU を実行していることを示している可能性があります。
どのアプリケーションが CPU を消費していますか?
20% メモリは ~1.6GB です。これは、Tomcat + mysql のみを実行しているアイドル状態のサーバーに期待するよりも少し多めです。は-Xms1024、Tomcat に 1GB のメモリを事前に割り当てるように指示するので、それが説明されます。
tomcat の設定を-Xms512およびに変更します-Xmx2048。一部のユーザーを投げている間、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 デバッガーで「一時停止」を押して、アプリケーションの動作を確認してください。各スレッドが現在実行しているコードとその呼び出しスタックを見てください。それを数回繰り返します。デッドロックや無限ループなどがある場合は、この方法で見つけることができます。
運が良ければ、問題はすでに見つかっているはずです。そうでない場合は、残念であり、アプリケーションの奥深くにある可能性のあるトリッキーなバグです。それは追跡するのが難しい場合があります。決意が成功へと導きます。頑張ってください=）
パフォーマンス関連の問題については、次の規則に従う必要があります。
-Xms2048m -Xmx2048m
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
ページが頻繁に変更されてこのオプションが論理的にならない場合は、動的コンテンツを一時的にキャッシュして、何度も再生成する必要がないようにしてください。再度実行するのではなく、既に実行された作業をキャッシュするために使用できる手法を使用する必要があります。これは、Tomcat の最高のパフォーマンスを達成するための鍵です。
データベース関連の問題がある場合は、SQL クエリのパフォーマンス チューニングに従うことができます。
Catalina.outログ ファイルをローテーションしますwithout restarting Tomcat。
詳しくは、2通りあります。
最初のより直接的な方法は、Catalina の起動シェル スクリプトで選択したログ ローテーション ツールに単純なパイプを追加することで、Catalina.out をローテーションできることです。これは次のようになります。
"$CATALINA_BASE"/logs/catalina.out WeaponOfChoice 2>&1 &
"WeaponOfChoice"お気に入りのログ ローテーション ツールに置き換えるだけです。
2 番目の方法は直接的ではありませんが、最終的には優れています。Catalina.out の回転を処理する最善の方法は、回転する必要がないことを確認することです。のすべてのコンテキストに対して「swallowOutput」プロパティを true に設定するだけ"server.xml"です。
これにより、構成した Logging の実装にSystem.errとがルーティングされます。構成していない場合は にルーティングされます。System.outJULI
同様の問題が発生しました。原因は「catalina.out」でした。これは、「System.out」および「System.err」の標準の宛先ログ ファイルです。サイズが大きくなり続けたため、速度が低下し、最終的にTomcatがクラッシュしました。この問題は、「catalina.out」をローテーションすることで解決されました。Redhat を使用していたので、「catalina.out」をローテーションするシェル スクリプトを作成しました。
ここにいくつかのリンクがあります： -
カタリナに関する Mulesoft の記事 (2 つのローテーション方法も含まれています):
「catalina.out」が問題でない場合は、代わりにこれを試してください:-
Tomcatの最適化に関する Mulesoft の記事: Tuning Tomcat Performance For Optimum Speed