ファイアウォールによるデータベース接続の中断
2457 ワード
先日、生成環境にプロジェクトが導入された後、同僚は、初めてビジネス機能を使用するときに、データをロードするのに長い間待たなければならないと反映し、再びこの機能を使用すると、すぐにデータをロードできます.この問題を聞いたばかりで、データ量が大きすぎて、最初のクエリーが遅いのではないかと思いました.それから、キャッシュが導入されたので、後のクエリーは速いですが、すぐにこの推測を排除しました.クエリーの条件を変えたので、結果は依然として速く、キャッシュの問題ではないことを説明し、sql文を直接データベースに持ってクエリーに行き、速度も遅くありません.感性的な推測は成り立たず、理性的な観点から調査を始め、まずシステムログを見てみると、やはり報告ミス情報を発見しました.
testQueryを実行中にエラーが発生しました.原因:ソフトウェアが接続を中断しました.受信に失敗しました.接続が中断しましたか?特に何の問題ですか.データベースが停止しましたか?理由がないでしょう、掛けて、瞬時にまた良いことがあり得なくて、二次アクセスの時、データのロード速度はまたすべて正常で、その上間違いを報告していないので、後でゆっくりと総括して、大体20分ぐらいあるデータインタフェースにアクセスしないで、このデータインタフェースはこの間違いを報告します.エラーメッセージから见ると、ここの接続中断とは、アプリケーションサーバーとデータベースサーバーの间の接続が中断したことを指すべきで、皆さんは知っていて、ここの接続はTCPプロトコルを采用して、TCPプロトコルが中断して、いくつかの可能性があります:1、接続の过程の中で、送信者と受信者の一方が突然接続を切断しました;2、応答者は、送信を要求する前から接続を切断していたが、送信者は知らなかった.3、要求側は応答側が応答する前にすでに接続を切断したが、応答側は知らない.私たちのプロジェクトにとって、アプリケーションサーバーは明らかに接続の発起人で、アプリケーションは受信に失敗しました.つまり、応答者は応答していません.上の第1と第2の状況に対応しています.応答者はデータベースサーバーで、検査を経て、このサーバーのネットワークはスムーズで、パケットをなくしたこともありません.だから、接続の過程で判断します.突然中断する可能性は低い.つまり、データベース・サーバがアプリケーションから要求を送信する前に、一方的に接続を中断したという2つ目のケースに属するはずだ.ここまで分析すると、我々のプロジェクトがatomikos接続プールを使用していることを考えると、接続プールはtcp長接続を採用している.すなわち、データベースサーバ側の対応する受信ポイントで接続セッションが閉じられているが、接続プール側は知らず、結果としてアプリケーションシーケンスがプールから接続を取得し、コミュニケーションを開始しようとすると、エラーが報告される.問題が発生しました.データベース・サーバが一方的に接続を中断するのはどのような場合ですか?ネット上で多くの資料を調べて、すべて重点を言っていないで、それからこの博文を見つけて、言うのはとても詳しくて、私の推測と基本的に一致して、具体的な参考:http://www.360doc.com/content/08/0524/18/49194_1281450.shtmlそう、ファイアウォールはアイドルのTCP接続をタイミングよく遮断し、設定時間は20-30分程度と推定され、解決方法も簡単でoracleのsqlnet.oraファイルには、SQLNETというコードが追加する.EXPIRE_TIME=10の意味は、oracleに10分ごとに、接続を保持しているクライアントに応答があるかどうかを探知し、応答のないクライアントとの接続OKをオフにすることです.皆さんは原理を理解しているでしょう.oracleは10分ごとにデータを送信してクライアントに応答があるかどうかを探知します.ファイアウォールはこれらの接続がアイドル接続だとは思いません(設定されたoracleプローブ周波数がファイアウォールのスキャン周波数よりも小さいため)、これらの接続を切断することはありません.接続プールのtestQueryメカニズムでは、接続が失効したことを検出した後、自動的に接続を再作成できますが、検出には間隔があり、この間隔は頻繁ではありません.そうしないとリソースも占有されます.検出間隔内で割り込みが発生した場合問題は、やはりデータのロードが遅く、ユーザー体験に影響を与えることがあります.
WARN [com.atomikos.datasource.pool.ConnectionPool] - atomikos connection pool 'gaOracleDataSource': error creating proxy of connection AtomikosNonXAPooledConnection
com.atomikos.datasource.pool.CreateConnectionException: Error executing testQuery
...
Caused by: java.sql.SQLRecoverableException: IO : Software caused connection abort: recv failed
...
Caused by: java.net.SocketException: Software caused connection abort: recv failedtestQueryを実行中にエラーが発生しました.原因:ソフトウェアが接続を中断しました.受信に失敗しました.接続が中断しましたか?特に何の問題ですか.データベースが停止しましたか?理由がないでしょう、掛けて、瞬時にまた良いことがあり得なくて、二次アクセスの時、データのロード速度はまたすべて正常で、その上間違いを報告していないので、後でゆっくりと総括して、大体20分ぐらいあるデータインタフェースにアクセスしないで、このデータインタフェースはこの間違いを報告します.エラーメッセージから见ると、ここの接続中断とは、アプリケーションサーバーとデータベースサーバーの间の接続が中断したことを指すべきで、皆さんは知っていて、ここの接続はTCPプロトコルを采用して、TCPプロトコルが中断して、いくつかの可能性があります:1、接続の过程の中で、送信者と受信者の一方が突然接続を切断しました;2、応答者は、送信を要求する前から接続を切断していたが、送信者は知らなかった.3、要求側は応答側が応答する前にすでに接続を切断したが、応答側は知らない.私たちのプロジェクトにとって、アプリケーションサーバーは明らかに接続の発起人で、アプリケーションは受信に失敗しました.つまり、応答者は応答していません.上の第1と第2の状況に対応しています.応答者はデータベースサーバーで、検査を経て、このサーバーのネットワークはスムーズで、パケットをなくしたこともありません.だから、接続の過程で判断します.突然中断する可能性は低い.つまり、データベース・サーバがアプリケーションから要求を送信する前に、一方的に接続を中断したという2つ目のケースに属するはずだ.ここまで分析すると、我々のプロジェクトがatomikos接続プールを使用していることを考えると、接続プールはtcp長接続を採用している.すなわち、データベースサーバ側の対応する受信ポイントで接続セッションが閉じられているが、接続プール側は知らず、結果としてアプリケーションシーケンスがプールから接続を取得し、コミュニケーションを開始しようとすると、エラーが報告される.問題が発生しました.データベース・サーバが一方的に接続を中断するのはどのような場合ですか?ネット上で多くの資料を調べて、すべて重点を言っていないで、それからこの博文を見つけて、言うのはとても詳しくて、私の推測と基本的に一致して、具体的な参考:http://www.360doc.com/content/08/0524/18/49194_1281450.shtmlそう、ファイアウォールはアイドルのTCP接続をタイミングよく遮断し、設定時間は20-30分程度と推定され、解決方法も簡単でoracleのsqlnet.oraファイルには、SQLNETというコードが追加する.EXPIRE_TIME=10の意味は、oracleに10分ごとに、接続を保持しているクライアントに応答があるかどうかを探知し、応答のないクライアントとの接続OKをオフにすることです.皆さんは原理を理解しているでしょう.oracleは10分ごとにデータを送信してクライアントに応答があるかどうかを探知します.ファイアウォールはこれらの接続がアイドル接続だとは思いません(設定されたoracleプローブ周波数がファイアウォールのスキャン周波数よりも小さいため)、これらの接続を切断することはありません.接続プールのtestQueryメカニズムでは、接続が失効したことを検出した後、自動的に接続を再作成できますが、検出には間隔があり、この間隔は頻繁ではありません.そうしないとリソースも占有されます.検出間隔内で割り込みが発生した場合問題は、やはりデータのロードが遅く、ユーザー体験に影響を与えることがあります.