RPC 接続が多すぎると Web ソケットが閉じられます

RPC 接続が多すぎると Web ソケットが閉じられます

複数のサーバーが RPC 経由で接続されています。OS 内のアプリで RPC 呼び出しが多すぎると、ネットワークが閉じてしまうことがあります。OS をデバッグまたは構成する最適な方法は何ですか?

"msg":"sending ping message: write tcp 127.0.0.1:36802->127.0.0.1:1234: use of closed network connection"
"msg":"handle me:write tcp4 127.0.0.1:1234->127.0.0.1:56244: write: broken pipe"

答え1

RPC 呼び出しが多すぎることが原因であるという結論に至るためにどのようなトラブルシューティングを行ったか、または障害発生時のネットワーク接続の状態に関する詳細は記載されていません。このエラーは、接続プールの不足によるポートの枯渇から発生しているものと思われます。

ポート枯渇をチェックするには、netstat を使用してサーバーのポートの状態を取得します。リストされているポートの数が多すぎる場合は、ポート枯渇の問題が発生している可能性があります。

gRPC は接続を自動的にプールしますが、コードが適切に記述されていない場合、既存の gRPC チャネルを再利用せずに新しい gRPC チャネルを過剰に作成することで、これが適切に機能しなくなる可能性があります。新しいチャネルを作成すると新しい HTTP/2 接続が作成される仕組みについて説明されている Microsoft のドキュメントを参照しました。

これを修正するには、コードを評価して、チャネルをより適切に再利用するように変更する必要があります。

gRPC のパフォーマンスのベスト プラクティス

gRPC 呼び出しを行うときは、gRPC チャネルを再利用する必要があります。チャネルを再利用すると、既存の HTTP/2 接続を介して呼び出しを多重化できます。

gRPC 呼び出しごとに新しいチャネルが作成されると、完了までにかかる時間が大幅に増加する可能性があります。各呼び出しでは、新しい HTTP/2 接続を作成するために、クライアントとサーバーの間で複数のネットワーク ラウンドトリップが必要になります。

パフォーマンスのベストプラクティス

可能な場合は常にスタブとチャネルを再利用します。

その際、TCP ソケットではなく Unix ドメイン ソケットを検討してください。これらのアプリケーションが最終的に複数のマシンに分散して動作する場合は、TCP ソケットを使用する必要があります。常に同じマシンで実行される場合は、Unix ドメイン ソケットを検討する必要があります。

scala/java で inet ではなくローカルソケット経由で GRPC サービスを作成する方法

Unix ドメイン ソケットを使用した Python の gRPC サーバー

関連情報