0

.net 4.5 ASP.NET WebAPI アプリケーションがあります。4 CPU の 8 ギガ VM で 1 ワーカーを使用して IIS にデプロイされました。

最近変更を加えました (アップグレードされた ServiceStack.Interfaces、ServiceStack.Common、ServiceStack.Redis、および多数の依存関係)。このアプリがデプロイされている IIS アプリ プールが 1 時間に 1 回 (数分かかるか、または数分かかります) リサイクルされることに気付き始めました。 ）。

私のアプリケーション ログには、何らかの問題を示すものは何もありません。Telegraf を使用してメトリクスを収集しますが、メモリ メトリクスの増加はまったく見られません。すべてのメトリクスが完全に正常に見え、アプリ プールがリサイクルされる限りです。

イベント ビューアーを見て、WAS ソースでログをフィルター処理すると、ID 5011 のイベントが表示されます。これは基本的に、IIS ワーカーがクラッシュしたことを意味します。

そこで、DebugDiag を使用して、自分のボックスにアプリを展開したローカル ボックスで実行しました (ローカルで問題を再現できます)。しばらく実行し、最終的にイベント ビューアーで同じイベントを取得しました。DebugDiag からのクラッシュ分析ログを調べたところ、多数の例外がログに記録されているかどうかがわかりましたが、クラッシュの直前に具体的なものは何もありませんでした。

現時点では、クラッシュの原因を突き止めるために他に何ができるか完全にはわかりません。そのため、透明性を高めるためにできることについて、さらに多くの提案があることを願っています。

私が考えているのは、依存関係の 1 つとアップグレードされたパッケージの一部との非互換性があり、例外がスローされ、何も処理されず、IIS ワーカーがクラッシュすることです。

すべての API エンドポイント機能に問題がなく、メモリが増加しておらず、CPU に問題がない限り、私のアプリケーションは完全に正常に動作しています。したがって、私が知る限り、クラッシュまで問題はありません。

クラッシュの原因を見つけたり、それを処理したりするためのトリックを誰かが知っているかどうか疑問に思って、この例外がワーカーをエスケープしてクラッシュするのを防ぎます。

4

1 に答える 1

0

問題が ServiceStack.Redis RedisPubSubServer 内のどこかにあるという確信を持って絞り込むことができました。実際の問題は何ですか。掘り下げるのにもっと時間がかかり、すでに多くの時間を無駄にしてしまったのでわかりません。

ただし、(ServiceStack が Sentinel をサポートする前から) 持っていた既存のコードに便乗して、LazySentinelServiceStackClientWrapper と呼ぶ redis クライアント ラッパーの新しい実装を作成しました。組み込みのセンチネル マネージャーを使用する代わりに、LazySentinelApiSentinelProvider を作成したカスタムのセンチネル プロバイダーに依存しますおよび読み取り専用ホストであり、このプールは redis 操作を実行するために使用されます。プールは、エラーが発生するたびに更新されます (フェールオーバー後)。ServiceStack に付属する組み込みのセンチネル マネージャーとは対照的です。

この redis クライアント ラッパーの私のバージョンをアプリケーションにインストールしましたが、それ以降 (スケジュールされたものを除いて) アプリ プールのリサイクル イベントが発生しませんでした。

ここに画像の説明を入力

上記は、ServiceStack.Redis センチネル マネージャーを無効にする前のアプリ プール リサイクル イベントのログです。

そして、これが新しい怠惰なセンチネル マネージャーをインストールした後のアプリ プールのリサイクル イベントのログです。

ここに画像の説明を入力

最初のスパイクは私が手動でアプリをリサイクルしたことで、2 つ目はスケジュールされた午前 1 時のリサイクルです。したがって、明らかに問題は解決されています。

redis pubサブサーバーを介したセンチネルマネージャーがIISラピッドフェイル保護を起動させ、アプリプールをリサイクルさせている実際の理由は何ですか? おそらく、redis の経験や IIS の経験がはるかに多い人がそれを証明できるでしょう。また、これは .net コアではテストせず、IIS に展開された .net 4.5.1 アプリケーションに対してのみテストしましたが、ローカル開発マシンや強力な運用マシンを含む多くの異なるマシンでテストしました。

最後に、すべてのリサイクル イベントを示す最初の画像です。これは、ほとんどトラフィックを処理していない CI マシン上にあり、おそらく数分ごとに 1 つのリクエストです。したがって、これは問題がメモリ リークやリソースの枯渇ではないことを意味します。問題が何であれ、トラフィック、CPU 負荷、メモリ負荷に関係なく、定期的に発生します。

言うまでもなく、少なくとも今のところ、組み込みのセンチネル マネージャーは使用しません。

于 2019-12-22T01:09:10.943 に答える