3
私は約7台のサーバ（C＃）で動作しているウェブサイトを持っています。そして、3つのインスタンスで動作するgRPCサービス（golang）があります。各WebサーバーはgRPCサービスに接続し、gRPCサービスを呼び出します。サービスには毎分約8000件の通話があります。毎時gRPCコールの急上昇
このサービスの呼び出しはそれほど重要ではないため、最近では、呼び出しの締め切りを20ミリ秒に短縮しました。ここで私たちは奇妙な何かに気づいた。 1日中1時間ごとに「期限超過」エラーが発生しました。そしてそれは、なぜこれが起こるのでしょうか？など、すなわち午後15時16時0次回分で正確に
起こりますか
this link gRPCが毎時接続をリセットすると言いましたが、それ以上のことはありません。
私の質問はgRPCが内部的に1時間ごとに接続をリフレッシュすることです。はいの場合は、この動作を調整するためにとにかくあります。もしそうでなければ、誰かが何が起こっているのかを私がどのようにデバッグすることができるかについてのある方向性を与えることができます。
私は、1つのgRPCサーバーインスタンスからランタイムトレースを30秒間収集することを勧めます。そのため、スパイクが疑われる前と15秒後に15秒があるようにします。 トレースは、 'curl 'のような処理を行うことで取得できます。http：// endpoint/debug/pprof/trace？seconds = 30'> runtime.trace' GC内のスパイクのような異常を分析できます。 トレースの使い方については、 'go tool trace --help'を参照してください。 '-http'フラグは、pprof対応のものを抽出するだけでなく、Chromiumのビルトインビジュアライザーを使ってトレースを表示することもできます。 詳細については、https://making.pusher.com/go-tool-trace/を参照してください。 – kostix
異常が1時間だけ正確に表示され、再起動してもスパイクがシフトしない場合は、あまりにも多くのリソースを取り込んでいるcronジョブのような外部システム要因を探すのが理にかなっています。私はC＃の実装について何も知らないけれども、ほとんどのシステムでは、これらのスパイクを防ぐために期限にジッタが加わります。クライアントで20msの締め切りを設定している場合は、新しい接続を行う必要があるときには十分にカバーできません。 – JimB
@kostix私はあなたが示唆したようにトレースを実行しました。私はgRPCサーバー上で異なる動作を見つけることができませんでした。私はまた、それぞれの呼び出しがサーバー上で実行されている時間を記録しました。私はJimBが何を提案し、クライアント側の問題を調べるかと考えています。 – pratikvasa