Ich arbeite an einigen .NET-Webanwendungen, die Redis zum Caching zusammen mit dem Redis-Client von ServiceStack verwenden. In allen Fällen habe ich Redis auf demselben Rechner laufen. Ich habe beide BasicRedisClientManager und PooledRedisClientManager (immer als Singletons implementiert) und hatte einige Probleme mit beiden Ansätze.
Mit BasicRedisClientManager würden die Dinge eine Weile gut funktionieren, aber Redis würde schließlich damit beginnen, Verbindungen abzuweisen. Mit netstat haben wir festgestellt, dass Tausende von TCP-Verbindungen zum Standard-Redis-Port im TIME_WAIT-Status herumhingen.
Wir sind dann zu PooledRedisClientManager gewechselt, was das Problem sofort zu beheben schien. Aber nicht lange danach bemerkten wir gelegentlich CPU-Spitzen, die wir auf Threading-Wartezeiten (System.Threading.Monitor.Wait-Aufrufe) beschränkten, verursacht durch PooledRedisClientManager.GetClient.
Im Code verwenden wir einen Get-In-Get-Out-Ansatz (mit den praktischen Execas-Shortcuts von ServiceStack). Daher werden Verbindungen in der Regel sehr häufig erfasst, aber so kurz wie möglich gehalten.
Wir bekommen eine geringe Menge an Traffic, aber wir sind kein StackExchange, und ich kann nicht umhin zu denken, dass der ServiceStack-Client dem Job gewachsen ist und wir nur etwas falsch machen. Ist PooledRedisClientManager der richtige Ansatz hier? Wäre es ratsam, einfach die Poolgröße zu erhöhen? Oder maskiert das wahrscheinlich nur ein Problem mit unserem Code?
Wenn ich hier nur nach einer allgemeinen Anleitung suche, habe ich keinen spezifischen Code, an dem ich zu diesem Zeitpunkt Hilfe brauche. Vielen Dank im Voraus.
Sind Sie absolut sicher, dass alle Redis-Verbindungen entsorgt werden?
Mit ServiceStack können Sie die Redis -Eigenschaft für Service und ViewPageBase (wenn Sie SS Razor verwenden) selbst dislozieren, aber jedes Mal, wenn Sie selbst eine Verbindung aus dem Pool anfordern, müssen Sie sie selbst entsorgen / p>
Trotzdem hatten wir kürzlich Probleme, dass unser Pool von allen Verbindungen erschöpft war. Einer meiner Kollegen fand heraus, dass es keine richtige Säuberung für Razor-Seiten gab und machte eine Pull-Anfrage hier - Dies bedeutet, dass die Razor-Seiten erst seit ServiceStack v4.0.21 korrekt entsorgt wurden. Ich habe nicht überprüft, ob dieser Fix in den v3-Zweig zurückportiert wurde.
Mein Kollege hat auch TrackingRedisClientsManager hinzugefügt, das Ihnen beim Aufspüren der unsachgemäßen Entsorgung helfen kann. Siehe hier
Sie können auch die Statistiken eines PooledRedisClientManager überprüfen mit dieser Hilfsmethode . Wir haben es auf eine kleine Rasierklingenseite geworfen, um die Statistiken zu überprüfen, so wie wir es für angebracht halten. Aber Sie könnten besseren Code schreiben, um die Pool-Gesundheit bestimmter Knoten zu überwachen.
Tags und Links redis servicestack connection-pooling