EF-Core und big-traffic führt zu max Poolgröße wurde erreicht Fehler

Verwenden wir ASP.NET Entity Framework-Kern für Abfragen unsere MSSQL-Datenbank-in unserem Web-API app. Manchmal, wenn wir große Verkehr, die Abfrage an die DB endet mit dieser Fehlermeldung:

Timeout ist abgelaufen. Das Zeitlimit wurde vor dem anfordern einer Verbindung aus dem pool. Dies stattgefunden haben könnte, weil alle zusammengefasste verbindungen wurden in verwendet und die maximale Poolgröße wurde erreicht.

Ich Frage mich, ob unserem Muster mit DbContext und die Abfrage korrekt ist, oder wenn ich bin fehlen einige verwenden/entsorgen, - Muster und-Fehler wird verursacht durch ein memory leak (nach einiger recherche Las ich dann, ich sollte nicht verwenden, verwenden, da die Lebensdauer wird geleitet von den Rahmenbedingungen). Ich bin nach Dokumentation...

Mein connectionString:

"myConnection": "Server=xxx;Database=xxx;user id=xxx;password=xxx;Max Pool Size=200;Timeout=200;"

Mein Start.cs

public void ConfigureServices(IServiceCollection services)
    {
    .....
    //scoped context            
    services.AddDbContext<MyDbContext>(
            options => options.UseSqlServer(this.Configuration.GetConnectionString("myConnection")));
    }

dann im Controller verwendete ich dbcontext von dependency injection:

public class MyController : Controller
   public MyController (MyDbContext context)
    {
        this.Context = context;            
    }

    public ActionResult Get(int id)
    {
        //querying
        return this.Context.tRealty.Where(x=>x.id == id).FirstOrDefault();
    }

Sollte ich so etwas wie:

using (var context = this.Context)
        {
            return this.Context.tRealty.Where(x => x.id == id).FirstOrDefault();
        }

Aber ich denke, dass dies ist eine schlechte Muster, wenn ich mit dependency injection von DbContext.

Scheint, wie Sie haben Ihre eigene Frage beantwortet.
Also sollte ich mit Verwendung wenn ich die Abfrage dbcontext wird Hinzugefügt, die durch dependency injection...
Der DI-container sollte kümmern sich um die Entsorgung der Kontext, also Nein.

InformationsquelleAutor Vít Zaoral | 2016-09-29

7

Ich denke, dass problem verursacht wurde, indem Objekte aus der Datenbank Abfragen im Zusammenhang zu In-memory-cache. Ich hatte eine große LINQ-Abfrage auf Datenbank-Kontext mit einigen anderen Unterabfragen in. Ich rief FirstOrDefault() auf das Ende der Haupt-Abfrage, aber nicht in Unterabfragen. Controller war in Ordnung mit ihm, es materialisieren Abfragen standardmäßig.
```
 return this.Context.tRealty.AsNoTracking().Where(
                x => x.Id == id && x.RealtyProcess == RealtyProcess.Visible).Select(
                s => new
                { .....

//subquery
videos = s.TVideo.Where(video => video.RealtyId == id && video.IsPublicOnYouTube).
                        Select(video => video.YouTubeId).ToList()), //missing ToList()
.....
 }).FirstOrDefault();
```
Und es war problem - Unterabfragen hielten Verbindung zum Datenbank-Kontext, wenn Sie wo speichern zu In-memory-cache. Wenn ich umgesetzt Redis verteilten cache, war es zunächst versagt, auf einige merkwürdige Fehler. Hilft es wenn ich Schreibe ToList() oder FirstOrDefault() alle meine Unterabfragen, weil verteilte cache muss der materialisierten Objekte.

Nun habe ich alle meine Fragen materialisiert explizit, und ich bekam keine max-pool-Größe wurde erreicht Fehler. Damit muss man vorsichtig sein, wenn die gespeicherten Objekte aus der Datenbank Abfragen im Zusammenhang zu In-memory-cache. Es ist notwendig, sich zu materialisieren, alle Abfragen zu vermeiden, halten Verbindung irgendwo im Speicher.
- AUTSCH, einfach auf diese. Hier ist eine SQL-Abfrage zum ermitteln der pool poopers : gist.github.com/jakenuts/eeb56da402b571ba6ca30c4fcffc7247
InformationsquelleAutor Vít Zaoral
2

Können Sie die Lebensdauer des DbContext im Autostart.cs, sehen, ob das hilft:
```
    services.AddDbContext<MyDbContext>(options => options
                                       .UseSqlServer(connection), ServiceLifetime.Scoped);
```
Auch wenn Ihre Abfrage ist ein einfaches Lesen, Sie können entfernen Sie das tracking durch die Verwendung .AsNoTracking().

Einen anderen Weg, Ihren Durchsatz zu erhöhen ist, um zu verhindern, dass sperren durch die Verwendung eines Transaktions-block mit IsolationLevel.ReadUncommitted für einfach liest.
Sie können auch die Snapshot isolation-level - das ist etwas mehr einschränken - wenn Sie nicht möchten, dass dirty reads.
```
TransactionOptions transactionOptions = new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUncommitted};
using (TransactionScope transactionScope = new TransactionScope(TransactionScopeOption.Required, transactionOptions))
{
  //insert magic here
}
```
Edit : Wie der Autor der Frage erwähnt, der obige code ist (noch?) nicht möglich das EF-Core.

Einen workaround gefunden werden kann hier mit einer expliziten Transaktion:
```
    using (var connection = new SqlConnection(connectionString))
    {
        connection.Open();

        using (var transaction = connection.BeginTransaction())
        {
           //transaction.Commit();
           //transaction.Rollback();
        }
    }
```
Habe ich nicht getestet.

Edit 2: eine Weitere ungetestete snippet, wo Sie haben, Befehle ausgeführt zu set isolation level:
```
                using (var c1= new SqlConnection(connectionString))
                {
                    c1.Open();
                    //set isolation level
                    Exec(c1, "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;");
                    Exec(c1, "BEGIN TRANSACTION;");
                    //do your magic here
                }
```
Mit Exec:
```
        private static void Exec(SqlConnection c, string s)
        {
            using (var m = c.CreateCommand())
            {
                m.CommandText = s;
                m.ExecuteNonQuery();
            }
        }
```
Edit 3: Nach dass thread, Transaktionen werden unterstützt .NET-Core-version 1.2 ab.

@mukundabrt dieser wird verfolgt von dotnet/corefx#2949. Beachten Sie, dass
TransactionScope hat bereits portiert wurde .NET Core wird jedoch nur
erhältlich in .NET Core 1,2.
- Lebensdauer der DbContext bezieht sich standardmäßig (per definition von AddDbContext - Methode)... Mit .AsNoTracking() ist eine gute Idee, weil mein api ist nur zu Lesen, danke. Aber ich denke, dass problem liegt irgendwo in bad schließen von verbindungen, AsNoTracking sollte einfach schneller Abfragen. EF-Core-ich glaube nicht, verwenden Sie TransactionScope da es nicht unterstützt wird für jetzt link
- Ist dein timeout Auftritt auf der Verbindungsebene ist, oder auf einen query-Ebene? Sie können auch versuchen, die Datenbank.CommandTimeout-Eigenschaft in bestimmten Fällen.
- Fehler aufgetreten, wenn ich einige LINQ-Abfrage. Ich habe TimeOut=200 in meinem connection-string, ich denke, es ist wirklich großen Wert für einfache get-Abfrage (unsere Anfragen werden schnell, bis die alle verbindungen verwendet werden, dann Fehler aufgetreten und die app ist Total tot. Wir können einfach starten Sie es.)
- Das Timeout in der Verbindungszeichenfolge für das timeout der Verbindung, nicht der Befehl. Sie können angeben, CommandTimeout-Wert in Zusammenhang.CommandTimeout, bevor Sie Ihre Abfrage, wenn es groß, und es wieder auf einen Standardwert nach. msdn.microsoft.com/en-us/library/...
- Ich bearbeitet meine Antwort mit eine UNGETESTETE explizite Transaktion code aus einer anderen Antwort, die Sie geben könnten, es zu versuchen.
- So, nun ist unsere api läuft ohne max pool size-wurde erreicht Fehler. Ich weiß nicht, ob es eine Verbindung, aber wir waren mit In Memory Caching in unserer app, um cache-Ergebnisse von Datenbank-Abfragen. Jetzt sind wir mit Redis Verteilten Cache und alles ist in Ordnung. Also schwer zu sagen...
- Froh, Sie geschafft zu Sortieren, Ihr Problem. Das ist seltsam, würde man erwarten, dass in-memory-caching nicht auf die Sammlung pool. Ist es möglich, dass unter bestimmten Bedingungen etwas in den cache verhindert wird, dass die db den Kontext der Entsorgung? Was war die Ablaufzeit des cache und habe es zu verändern, haben keine Wirkung?
- Ja, ich denke, dass problem wurde mit der Speicherung von Objekten aus der Datenbank Abfragen im Zusammenhang mit der In-memory-cache. Verfall-Zeit war 2 Stunden (absolute Ablaufzeit) eine änderung keine Auswirkung hat. Ich beschreibe mal meine Lösung in der Antwort...
InformationsquelleAutor Darxtar
1

Ich bin das hinzufügen einer alternativen Antwort, falls irgendjemand landet hier mit einem etwas anderen Ursache, wie bei meinem .NET-Core-MVC-Anwendung.

In meinem Szenario die Anwendung war die Herstellung dieser "timeout ist abgelaufen... max Poolgröße wurde erreicht" Fehler durch gemischte Nutzung von async/await und Task.Result innerhalb der gleichen Steuerung.

Ich dies getan hatte, in einem Versuch, um die Wiederverwendung von code durch den Aufruf einer bestimmten asynchronen Methode in meinem Konstruktor, um eine Immobilie. Da Konstruktoren nicht erlauben asynchrone Aufrufe, ich war gezwungen zu verwenden Task.Result. Allerdings war ich mit async Task<IActionResult> Methoden zu await Datenbank Anrufe innerhalb des gleichen controller. Wir beschäftigen Microsoft Support, und ein Ingenieur half erklären, warum dies geschieht:

Aussieht, machen wir einen blockierenden Aufruf einer Asynchronen Methode in
[...] Konstruktor.

...

So, im Grunde etwas ist schief in dem Aufruf oben
markierte async-Methode und weil die alle threads aufgelistet
oben sind blockiert.

Blick auf die threads, die genau dieselbe operation und blockiert:

...

85.71% der threads blockiert (174 Beiträge)

Wir sollten vermeiden, mischen von asynchronen und blocking-code. Gemischter async und
blockieren von code führen kann, deadlocks, mehr-komplexe Fehlerbehandlung und
unerwartete Blockierung der Kontext-threads.

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

https://blogs.msdn.microsoft.com/jpsanders/2017/08/28/asp-net-do-not-use-task-result-in-main-context/

Aktionsplan

Bitte sprechen Sie Ihre Anwendung team zu überdenken, die den code der Anwendung der oben genannten Methode zu verstehen, was Los ist
falsch.

Außerdem würde ich es begrüßen, wenn Sie könnte, aktualisieren Sie Ihre Anwendung Logik
nicht mischen, asynchronen und blocking-code. Könnten Sie erwarten Task statt
Aufgabe.Warten oder Aufgabe.Ergebnis.

Also in unserem Fall zog ich die Task.Result aus dem Konstruktor und zog Sie in einen privaten async Methode, wo wir await es. Dann, da ich nur wollen, dass es zur Ausführung des tasks einmal pro Nutzung der controller, Speicher ich das Ergebnis, dass die local-Eigenschaft, und führen Sie die Aufgabe innerhalb dieser Methode nur, wenn der Wert der Eigenschaft ist null.

In meiner Verteidigung, ich erwartet, dass der compiler mindestens werfen, eine Warnung sein, wenn das mischen von asynchronen und blocking code ist so problematisch. Jedoch, es scheint offensichtlich genug, um mich, im Nachhinein!

Ich hoffe, dies hilft jemand...

InformationsquelleAutor Kevin M. Lapio

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Aktionsplan