Webサイトが正しく機能しない可能性があるため、すべての問題を体系的にチェックすることが困難になる理由はいくつかあります。以下は、Webサイトをクラッシュさせる最も一般的な問題の分析に焦点を当てます。これらの一般的な問題を解決できれば、いくつかの予期しない状況に対処することができます。
ディスクがいっぱいです
システムが正しく動作しない原因として最も可能性が高いのは、ディスクがいっぱいです。優れたネットワーク管理者は、ディスクの使用量に細心の注意を払いますが、ディスクの負荷の一部をバックアップ用の記憶媒体（テープなど）に転送する必要がある場合もあります。
ログファイルの空き容量がすぐになくなります。 Webサーバーのログファイル、SQL * Netのログファイル、JDBCのログファイル、およびアプリケーションサーバーのログファイルはすべて、メモリリークに対して同様に有害です。ログファイルをオペレーティングシステムとは異なるファイルシステムに保存する手順を実行できます。ログファイルシステムのスペースがいっぱいになるとWebサーバーも一時停止されますが、マシン自体が一時停止される可能性は大幅に減少します。
Cポインターエラー
WebサーバーAPIモジュールなどのCまたはC ++で書かれたプログラムは、間接参照ポインターにエラーが発生している限り（つまり、指摘されたメモリへのアクセス）、システムクラッシュを引き起こす可能性があります。オペレーティングシステムにすべてのプログラムを終了させます。さらに、悪いCポインターを使用するJavaアナログは、空のオブジェクト参照にアクセスします。 Javaでのnull参照は通常JVMを即時に終了させませんが、プログラマが例外処理を使用してエラーを適切に処理できる場合に限ります。この点に関して、Javaはあまり注意を払う必要はありませんが、信頼性に関する追加の測定基準としてJavaを使用すると、パフォーマンスに悪影響を与える可能性があります。
メモリリーク
C /C ++プログラムは別のポインタの問題を引き起こす可能性があります。割り当てられたメモリへの参照を失うことです。この問題は通常、サブルーチン内にメモリが確保されている場合に発生するため、サブルーチンから戻ったときにメモリを解放しません。その結果、割り当てられたメモリへの参照は失われ、オペレーティングシステムがまだ実行されている限り、プロセスはメモリを使用し続けます。その結果、より多くのメモリを使用しているプログラムは、マシンが完全に停止し、メモリが完全に空になるまでシステムパフォーマンスを低下させます。
解決策の1つは、コード分析ツール（Purifyなど）を使用してコードを慎重に分析し、潜在的なリークを特定することです。ただし、この方法では、ライブラリのソースコードが利用できないため、他の理由でライブラリ内のリークを見つけることができません。もう1つの方法は、定期的にプロセスをクリアして再開することです。このため、Apache Webサーバーは子プロセスを作成してクリーンアップします。
Java自体にはポインタがありませんが、一般に、JavaプログラムはCプログラムよりもメモリの使用量が多くなります。 Javaでは、オブジェクトは頻繁に作成され、オブジェクトへの参照がすべて消えるまでガベージコレクタはメモリを解放します。ガベージコレクタが実行されていても、オペレーティングシステムではなく仮想マシンVMにのみメモリを返します。その結果、Javaプログラムはすべてのヒープを使用し、解放することはありません。ジャストインタイム（JIT）コンパイラによって生成されたコードのため、Javaプログラムのサイズは最大ヒープサイズの数倍に拡大することがあります。
それでも問題があります、状況は似ています。データベース接続は接続プールから割り当てられ、割り当てられた接続を接続プールに戻すことはできません。一部の接続プールには、一定時間非アクティブになった後にデータベース接続を解放するアクティビティタイマーがありますが、これは悪いコードがデータベース接続を急速にリークすることによって引き起こされるリソースの浪費を軽減するのに十分ではありません。
ファイル記述子がプロセスにありません
ファイル記述子がWebサーバーまたは他の重要なプロセスに割り当てられているが、より多くのファイル記述子が必要な場合、サーバーまたはプロセスは中断されるかエラーが報告されます。必要なファイル記述子が取得されるまでファイル記述子は、オープンファイルとオープンソケットを追跡するために使用され、オープンファイルとオープンソケットはWebサーバーの重要なコンポーネントであり、ファイルをネットワーク接続にコピーすることを目的としています。デフォルトでは、ほとんどのシェルは64個のファイル記述子を持っています。つまり、シェルから開始される各プロセスは64個のファイルとネットワーク接続を同時に開くことができます。ほとんどのシェルにはファイル記述子の数を増やすulimitコマンドが埋め込まれています。
スレッドのデッドロック
マルチスレッドによるパフォーマンスの向上は、主にスレッドのデッドロックを引き起こす可能性があるため、信頼性を犠牲にしています。スレッドがデッドロックされると、最初のスレッドは2番目のスレッドがリソースを解放するのを待ち、2番目のスレッドは最初のスレッドがリソースを解放するのを待ちます。状況を想像してみましょう：二人はお互いに道を譲るために、舗装の上に頭を満たし、他の側に一歩を踏み出すために、彼らは両方とも、側への一歩を踏み出す双方が通過することができず、同時に、まだ通過していないこと。両側が同じ方法で反対側の方法をブロックしました。この状況が続くと仮定すると、なぜデッドロックが発生したのかを理解するのは難しくありません。
デッドロックを解決する簡単な方法はありません。スレッドにこの種の問題を発生させるのは非常に特殊な状況であり、負荷が非常に高い場合が多いためです。ほとんどのソフトウェアテストでは十分な負荷が発生しないため、すべてのスレッドエラーを公開することは不可能です。スレッドを使用するすべての言語にスレッドデッドロックの問題があります。 Javaを使用したスレッドプログラミングはCを使用するよりも簡単なので、Javaプログラマーでスレッドを使用する人が増え、スレッドデッドロックが一般的になりつつあります。 Javaコードで同期キーワードの使用を増やしてデッドロックを減らすことができますが、そうすることもパフォーマンスに影響を与える可能性があります。負荷が大きすぎると、データベース内にデッドロックが発生する可能性があります。
プログラムがロックファイルなどの恒久的なロックを使用していて、プログラムの終了時にプログラムがロック解除されていない場合、他のプロセスはこのタイプのロックを使用できず、ロックもロック解除もできません。これにより、システムが正しく機能しなくなります。この時点で手動でロックを解除する必要があります。
サーバーの過負荷
Netscape Web Serverは、接続ごとに1つのスレッドを使用します。 Netscape Enterprise Webサーバーは、スレッドがなくなると、既存の接続にサービスを提供せずにハングします。サーバーが応答していないことを検出する負荷分散メカニズムがある場合、そのサーバーの負荷は他のWebサーバーに分散される可能性があります。これにより、これらのサーバーはすべてのスレッドを1つずつ使い果たす可能性があります。その結果、サーバーグループ全体が中断されます。オペレーティングシステムレベルでは引き続き新しい接続を受信できますが、アプリケーション（Webサーバー）はこれらの接続を処理できません。ユーザーは接続されたメッセージをブラウザのステータス行に表示できますが、今後は何も起こりません。 //コンピュータのハードウェアおよびソフトウェアのネットワークwww.45it.com
問題を解決する方法のアプリケーションからのこの記事では、RqThrottleのスレッドの数以下の値のためのobj.confパラメータの値を設定するので、交差RqThrottleの値であれば、新しい接続を受け取りません。接続できないサーバーは機能しなくなり、接続中のサーバーは遅くなりますが、少なくとも接続されているサーバーは中断されません。この時点で、ファイル記述子は少なくともスレッド数と同じ数に設定する必要があります。そうしないと、ファイル記述子がボトルネックになります。
データベースのテンポラリテーブルが足りない
多くのデータベースのテンポラリテーブル（カーソル）の数は固定されており、テンポラリテーブルはクエリ結果のメモリ領域を保持します。一時テーブルのデータが読み取られた後に、一時テーブルが解放されます。ただし、多数の同時クエリが固定数のすべての一時テーブルを使い果たすことがあります。現時点では、他のクエリは実行を継続する前に一時テーブルが解放されるまでインラインで待機する必要があります。
これはプログラマによっては容易に気付かれない問題ですが、ロードテスト中に明らかになります。しかしデータベース管理者（データベース管理者、DBA）にとって、この問題は非常に明白です。
さらに、他にもいくつか問題があります。設定されたテーブルスペースが十分ではなく、シリアル番号の制限が低すぎるため、テーブルオーバーフローエラーが発生します。これらの問題は、運用に使用されるデータベース設定とパフォーマンスを定期的にチェックするための優れたDBAの重要性を示しています。さらに、ほとんどのデータベースベンダーは、これらの問題を解決するための監視およびモデリングツールも提供しています。
また、Webサイトが機能しなくなる可能性が最も高い要因は多数あります。相関関係、サブネットトラフィックの過負荷、貧弱なデバイスドライバ、ハードウェア障害、エラーファイルを含むワイルドカード、誤ってロックされたキーテーブルなど。