web-dev-qa-db-ja.com

StackExchange.Redisタイムアウト

本番環境は_Redis Cache Standard 2.5GB_を使用してAzure上にあります。

例1

System.Web.HttpUnhandledException（0x80004005）：タイプ「System.Web.HttpUnhandledException」の例外がスローされました。 ---> StackExchange.Redis.RedisTimeoutException：SETNX User.313123を実行するタイムアウト、inst：49、mgr：非アクティブ、err：never、queue：0、qu：0、qs：0、qc：0、wr：0、wq ：0、in：0、ar：0、clientName：PRD-VM-WEB-2、serverEndpoint：Unspecified/Construct3.redis.cache.windows.net：6380、keyHashSlot：15649、IOCP：（Busy = 0、Free = 1000、Min = 1、Max = 1000）、WORKER：（Busy = 1、Free = 32766、Min = 1、Max = 32767）（タイムアウトを引き起こす可能性があるいくつかの一般的なクライアント側の問題については、この記事をご覧ください： http://stackexchange.github.io/StackExchange.Redis/Timeouts ）at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl [T]（Message message、ResultProcessor1 processor, ServerEndPoint server) in c:\code\StackExchange.Redis\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 2120 at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor 1 processor、ServerEndPoint server） c：\ code\StackExchange.Redis\StackExchange.Redis\StackExchange\Redis\RedisBase.cs：line 81

例2

StackExchange.Redis.RedisTimeoutException：GET ForumTopic.33831を実行するタイムアウト、inst：1、mgr：非アクティブ、err：never、queue：2、qu：0、qs：2、qc：0、wr：0、wq：0、in ：0、ar：0、clientName：PRD-VM-WEB-2、serverEndpoint：Unspecified/Construct3.redis.cache.windows.net：6380、keyHashSlot：5851、IOCP：（Busy = 0、Free = 1000、Min = 1、Max = 1000）、WORKER：（Busy = 1、Free = 32766、Min = 1、Max = 32767）（タイムアウトを引き起こす可能性があるいくつかの一般的なクライアント側の問題については、この記事をご覧ください： http://stackexchange.github.io/StackExchange.Redis/Timeouts ）at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl [T]（Message message、ResultProcessor1 processor, ServerEndPoint server) in c:\code\StackExchange.Redis\StackExchange.Redis\StackExchange\Redis\ConnectionMultiplexer.cs:line 2120 at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor 1 processor、ServerEndPoint server）in c：\ code\StackExchange.Redis\StackExchange.Redis\StackExchange\Redis\RedisBase.cs：line 81 at StackExchange.Redis.RedisDatabase.StringGet（RedisKey key、CommandFlags flags）in c：\ code\StackExchange.Redis\StackExchange.Redis\StackExchange\Redis\RedisDatabase.cs：line 1647 at C3.Code.Controls.Application.Caching.D istributed.DistributedCacheController.Get [T]（String cacheKey）in C：\ Construct.net\Source\C3Alpha2\Code\Controls\Application\Caching\Distributed\DistributedCacheController.cs：line 115 at C3.Code.Controls.Application.Caching .Manager.Manager.Get [T]（String key、Func`1 getFromExternFunction、Boolean skipLocalCaches）in C：\ Construct.net\Source\C3Alpha2\Code\Controls\Application\Caching\Manager\Manager.cs：line 159 C.\Construct.net\Source\C3Alpha2\PageControls\Forums\TopicRender.ascx.cs：line 40のC3.PageControls.Forums.TopicRender.Page_Load（Object sender、EventArgs e）はSystem.Web.UI.Control.OnLoadの40行目（EventArgs e）System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Control.LoadRecursive （）System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Control.LoadRecursive（）at System.Web.UI.Page.ProcessRequestMain（Boolean includeStagesBeforeAsyncPoint、ブールincludeSt agesAfterAsyncPoint）

これらのエラーは1日に数回散発的です。

これはAzureネットワークの問題ですか、それとも軽減できるものですか？エラーの数値を確認しても、異常ではないように思われ、サーバーの負荷がAzureから報告された7％を超えることはありません。

Redis接続

_internal static class RedisController
{
    private static readonly object GetConnectionLock = new object();
    public static ConnectionMultiplexer GetConnection()
    {
        if (Global.RedisConnection == null)
        {
            lock (GetConnectionLock)
            {
                if (Global.RedisConnection == null)
                {
                    Global.RedisConnection = ConnectionMultiplexer.Connect(
                        Settings.Deployment.RedisConnectionString);
                }
            }
        }
        return Global.RedisConnection;
    }
_
azureredistimeoutstackexchange.redis
15
Tom Gullen

タイムアウトを引き起こす可能性のあるシナリオは3つあり、どちらが機能しているかを知るのは困難です。

  1. ライブラリがつまずきます。特に、TLS実装と、ライブラリのv1。*バージョンでの読み取りループの処理方法に関する既知の問題があります。これは、lotの時間を費やしたものです。 v2。*に取り組んでいます（ただし、特定のバージョンに依存する他のコードの一部としてライブラリを使用している場合は特に、v2に更新するのは常にではありません ）
  2. サーバー/ネットワークが作動しています。これは非常に現実的な可能性です。 "slowlog"を見ると、サーバー側の場合に役立ちますが、それを確認することはできません。
  3. サーバーとネットワークは問題なく、ライブラリはそれを実行していますが、クライアントとサーバーの間を飛んでいる巨大なブロブが他の操作を遅らせています。これは、現在を特定するのに役立つように変更を加えているものです。これが一般的な問題であることがわかった場合は、同時接続をより効果的に使用することを検討します。 （帯域幅は増えませんが、ブロックされた操作のレイテンシを減らすことができます）-これはv2のみの変更です。注意
4
Marc Gravell

遅延接続

ベストプラクティスとして、次のパターンを使用してStackExchange Redisクライアントに接続していることを確認してください。

_private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() => {
    return ConnectionMultiplexer.Connect("cachename.redis.cache.windows.net,ssl=true,abortConnect=false,password=password");
});

public static ConnectionMultiplexer Connection {
    get {
        return lazyConnection.Value;
    }
}
_

上記の方法が機能しない場合は、リージョン、帯域幅、NuGetパッケージのバージョンなどについて、 ソース1 で説明されているデバッグルートがいくつかあります。

IOスレッド

もう1つのオプションは、最小スレッド数を増やすことです。IOスレッド。多くの場合、IOCPスレッドとWORKERスレッドの最小構成値をデフォルト値よりも大きい値に設定することをお勧めします。 -あるアプリケーションの正しい値が別のアプリケーションに対して高すぎる/低すぎるため、この値がどうあるべきかに関するすべてのガイダンス。適切な開始場所は200または300であり、必要に応じてテストして微調整します。

この設定の構成方法：

  • ASP.NETでは、_ _<processModel>_ 構成要素の下にあるminIoThreads構成設定を使用しますmachine.config。 Microsoftによると、web.configを編集してサイトごとにこの値を変更することはできません（過去に可能であったとしても）。そのため、ここで選択する値は、すべての.NETサイトが使用する値です。 autoConfigをfalseに設定している場合、すべてのプロパティを追加する必要はありません。_autoConfig="false"_を入力し、値をオーバーライドするだけで十分です：_<processModel autoConfig="false" minIoThreads="250" />_

重要な注意：この構成要素で指定される値は、コアごとの設定です。たとえば、4コアマシンがあり、実行時にminIOThreads設定を200にしたい場合は、_<processModel minIoThreads="50"/>_を使用します。

  • ASP.NET以外の場合は、 ThreadPool.SetMinThreads（） APIを使用します。
  • 。Net Coreで、環境変数COMPlus_ThreadPool_ForceMinWorkerThreadsを追加して、デフォルトのMinThreads設定を上書きします 環境/レジストリ構成ノブ -上記と同じThreadPool.SetMinThreads()メソッドも使用します。

出典：

  1. Microsoft Azure-Azure Redis CacheのStackExchange.Redisでのタイムアウト例外の調査
  2. StackExchange.Redis
4
janniks

ネットワークトラフィックモニターをオンにして、メッセージを確認/拒否します。問題の解決策はありますが、大まかな解決策です。オプション1-Azureでマネージドredis instamceを再起動してみてください。

0
Srini Sydney

私の推測では、ネットワークの安定性に問題があるため、タイムアウトが発生しています。

誰もresponseTimeoutの増加について言及していないので、私はそれで遊んでみます。デフォルト値は50msで、簡単に到達できます。 200msを試してみて、メッセージに役立つかどうかを確認します。

構成オプション から取得：

_responseTimeout={int}   ResponseTimeout     SyncTimeout     Time (ms) to decide whether the socket is unhealthy
_

これについては、githubで複数の問題が開かれています。すべてを組み合わせたものはおそらく ＃871「ネットワークの安定性」/ 2.0 /「パイプライン」のロールアップの問題

もう1つ：代わりにConnectionMultiplexer.ConnectAsync()を試してみましたか？ConnectionMultiplexer.Connect()？

0
tukan