TCP再送信の根本原因の特定

TCP再送信の根本原因の特定

当社には、Firebird (v2.5.3) データベースに接続された Apache サーバー上で実行される、サードパーティ アプリケーションに基づく製品があります。

残念ながら、ユーザーがサーバーにリクエストを送信しようとするとタイムアウトが発生するようになりました。開発ツール -> ネットワーク タブを開くと、パケットがドロップされていることがわかります。

この問題をデバッグするために、サーバー上の Wireshark トラフィックを記録しましたが、多くの再送信イベントが確認されました。一部の HTTP パケットは正常に渡されますが、一部は再送信されており、これがタイムアウトの原因であると思われます。

サーバーの CPU 使用率は高くなっています (50 ~ 100%)。これは主に Firebird データベースが原因です。サーバーがホストされているクラウド プロバイダーには SSD ディスクがないため、これが問題になる可能性があることは認識しています。

奇妙なことに、Wireshark の記録では、ユーザーからの http リクエストが表示されないことがあります。受信されたパケットは次のようになります。

ここに画像の説明を入力してください

特定の IP からの失敗したリクエストをキャッチしようとしたところ、TCP 再送信のみが返されました (そのため、リクエスト自体は表示されません)。重要かどうかはわかりませんが、接続はポート 443 で行われています。これは、その例です。

ここに画像の説明を入力してください

  1. Firebird データベースがビジー状態または CPU 使用率が高いために、Wireshark に http 要求を登録しなくても、http パケットが遅い時間 (4 ~ 5 秒後) にドロップされる可能性はありますか?

  2. ディスクを SSD に変更することはできないので、CPU をアップグレードするとこの問題が解決すると思いますか?

  3. パフォーマンスを向上できる Apache または Firebird の設定はありますか?

問題についてさらに情報を得るために収集できる他の情報はありますか?

関連情報