Ich habe eine WCF-Dienstanwendung, die in IIS gehostet wird. Beim Start ruft sie eine sehr teure (in Bezug auf Zeit und CPU) Ressource ab, die als lokaler Cache verwendet wird.
Leider scheint IIS den Prozess ziemlich regelmäßig zu wiederholen. Daher versuche ich, die Einstellungen im Anwendungspool zu ändern, um sicherzustellen, dass IIS die Anwendung nicht wiederholt. Bisher habe ich Folgendes geändert:
- Begrenzen Sie das Intervall unter CPU von 5 bis 0.
- Leerlauf-Timeout unter Prozessmodell von 20 auf 0.
- Regelmäßiges Zeitintervall beim Recycling von 1740 bis 0.
Wird das ausreichen? Und ich habe konkrete Fragen zu den Punkten, die ich geändert habe:
- Was genau bedeutet die Einstellung „Intervall begrenzen“ unter „CPU“? Bedeutet dies, dass der Anwendungspool erneut verwendet wird, wenn eine bestimmte CPU-Auslastung überschritten wird?
- Was genau bedeutet „recycelt“? Wird die Anwendung komplett abgebaut und neu gestartet?
- Was ist der Unterschied zwischen „Worker Process Shutdown“ und „Application Pool Recycling“? In der Dokumentation zum Idle Time-out unter Process Model wird vom Herunterfahren des Worker-Prozesses gesprochen. In der Dokumentation zum Regular Time Interval unter Recycling wird vom Application Pool Recycling gesprochen. Ich verstehe den Unterschied zwischen den beiden nicht ganz. Ich dachte, w3wp.exe sei der Worker-Prozess, der den Application Pool ausführt. Kann jemand den Unterschied zwischen den beiden für die Anwendung erklären?
Der Grund für die Verwendung der Tags IIS7 und IIS7.5 liegt darin, dass die App in beiden Versionen ausgeführt wird und die Antworten in beiden Versionen identisch sein sollten.
Bild als Referenz:
Antwort1
Recycling
Beim Recycling startet IIS normalerweise* einen neuen Prozess als Container für Ihre Anwendung und gibt dann den alten auf, damit er ShutdownTimeLimitvon selbst verschwindet, bevor er beendet wird.
*- normalerweise: siehe DisallowOverlappingRotation/ Einstellung „Überlappendes Recycling deaktivieren“
Es istdestruktiv, indem der ursprüngliche Prozess und alle seine Statusinformationen verworfen werden. Sie können dieses Problem umgehen, indem Sie einen Sitzungsstatus außerhalb des Prozesses verwenden (z. B. einen Statusserver oder eine Datenbank oder sogar ein Cookie, wenn Ihr Status sehr klein ist).
Aber es ist standardmäßigüberlappend- Das bedeutet, dass die Dauer eines Ausfalls minimiert wird, weil der neue Prozess gestartet und an die Anforderungswarteschlange angeschlossen wird, bevor dem alten mitgeteilt wird: „Sie haben [ ShutdownTimeLimit] Sekunden, um zu verschwinden. Bitte kommen Sie der Anweisung nach.“
Einstellungen
Zu Ihrer Frage: Alle Einstellungen auf dieser Seite steuern das Recycling in gewisser Weise. „Herunterfahren“ könnte als „proaktives Recycling“ beschrieben werden – wo der Prozess selbst entscheidet, wann es Zeit ist, zu gehen, und auf geordnete Weise beendet wird.
Beim reaktiven Recycling erkennt WAS ein Problem und beendet den Prozess (nachdem ein geeigneter Ersatz-W3WP eingerichtet wurde).
Hier sind einige Dinge, die in der einen oder anderen Form zu Recycling führen können:
- ein ISAPI, das entscheidet, dass es nicht gesund ist
- jedes Modul stürzt ab
- Leerlauf-Timeout
- CPU-Begrenzung
- Anpassen der App Pool-Eigenschaften
- als deine MamaMaihaben an einem Punkt geschrien: „HaltKommissionierungsonst wird es nie besser!"
- „Ping“-Fehler * kein wirklicher Ping an sich, da eine benannte Pipe verwendet wird – mehr „Lebenserkennung“
- alle Einstellungen im Screenshot oben
Was zu tun:
Allgemein:
DeaktivierenLeerlauf-Timeouts. 20 Minuten Inaktivität = bumm! Alter Prozess weg! Neuer Prozess bei der nächsten eingehenden Anfrage. Setzen Sie das auf Null.
DeaktivierenRegelmäßiges Zeitintervall- Die 29-Stunden-Vorgabe wurde von verschiedenen Seiten als „verrückt“, „nervig“ und „clever“ bezeichnet. Tatsächlich sind nur zwei dieser Aussagen richtig.
OptionalAnmachenRotation bei Konfigurationsänderung nicht zulassen(über,Deaktivieren Sie das Recycling für Konfigurationsänderungen), wenn Sie einfach nicht aufhören können, damit herumzuspielen – damit können Sie jede App-Pool-Einstellung ändern, ohne dass den Arbeitsprozessen sofort signalisiert wird, dass sie beendet werden müssen. Sie müssen den App-Pool manuell recyceln, damit die Einstellungen wirksam werden. So können Sie Einstellungen vorab festlegen und sie dann über ein Änderungsfenster über Ihren Recyclingprozess anwenden.
Als allgemeines Prinzip gilt:verlassenPingenermöglicht. Das ist Ihr Sicherheitsnetz. Ich habe Leute gesehen, die es ausgeschaltet haben, und dann hängt die Site manchmal auf unbestimmte Zeit, was zu Panik führt. Wenn die Einstellungen also zu aggressiv für Ihre anscheinend sehr, sehr langsam reagierende App sind, schrauben Sie sie ein wenig zurück und sehen Sie, was passiert, anstatt es auszuschalten. (Es sei denn, Sie haben über Ihren eigenen Überwachungsprozess ein automatisches Dumping im Absturzmodus für hängende W3WPs eingerichtet.)
Das reicht aus, um einen gut funktionierenden Prozess für immer am Leben zu erhalten. Wenn er stirbt, wird er natürlich ersetzt. Wenn er hängt, sollte Ping das erkennen und innerhalb von 2 Minuten ein neuer starten (standardmäßig; die Worst-Case-Berechnung sollte lauten: bis zuPing-Frequenz+Ping-Zeitüberschreitung+Startzeitlimitbevor die Anfragen wieder funktionieren).
CPU-Begrenzung ist nichtnormalerweiseinteressant, denn standardmäßig ist es ausgeschaltet und auch so konfiguriert, dass es sowieso nichts tut; wenn es so konfiguriert wäre, dass es den Prozess beendet, wäre das natürlich ein Recycling-Trigger. Lassen Sie es ausgeschaltet. Hinweis: Für IIS 8.x wird auch die CPU-Drosselung eine Option.
Ein (IIS) AppPool ist keine (.Net) AppDomain (kann aber eine/einige enthalten)
Aber... dann kommen wir in .Net Land und AppDomainRecycling, das ebenfalls einen Zustandsverlust zur Folge haben kann. (Siehe:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)
Kurz gesagt, Sie tun dies, indem Sie eine web.config-Datei in Ihrem Inhaltsordner berühren (nochmal mit dem pflücken!), oder indem Sie in diesem Ordner einen Ordner oder eine ASPX-Datei erstellen oder ... andere Dinge ... und das istumso destruktiv wie ein App Pool-Recycling,Minusdie Startkosten des nativen Codes (es handelt sich ausschließlich um ein verwaltetes Code-Konzept (.Net), daher wird hier nur die Initialisierung des verwalteten Codes durchgeführt).
Auch ein Antivirus kann dies auslösen, da er web.config-Dateien scannt und eine Änderungsbenachrichtigung auslöst, die wiederum Folgendes verursacht:...
Antwort2
Bitte überprüfen Sie,
Warum recyceln wir unsere Anwendungspools?
Wenn Sie im Internet nach dem Grund suchen, warum Anwendungspools so konfiguriert sind, dass sie regelmäßig automatisch recycelt werden,Sie werden kaum eine vernünftige Antwort finden, die nicht mit Speicherproblemen zusammenhängt. Es ist, als ob die Community im Allgemeinen die Tatsache akzeptiert hat, dass unsere Webanwendungen(oder in IIS gehostete Serviceebenen) müssen erneut verwendet werden, um Speicherprobleme zu vermeiden.
Ich war immer der Meinung, dassWenn Ihr Code regelmäßige Neustarts erfordert, um weiterhin ordnungsgemäß zu funktionieren, dann stimmt eindeutig etwas nicht. Es gibt einen Fehlerin Ihrem Code und Sie müssen dies beheben, anstatt den Prozess gelegentlich neu zu starten, um das Problem zu „beheben“.
Wir müssen uns wirklich mehr konzentrieren aufSpeicherverwaltungin .NET und darauf, sicherzustellen, dass unsere Anwendungen weiterhin reibungslos laufen.
Antwort3
Basierend auf dem OP-Szenario (lange Initialisierung beim Start / Aufwärmen) ist eine weitere zu überprüfende SacheStartzeitlimit(Sekunden), der Standardwert beträgt 90 Sekunden. Wenn die Initialisierung länger als das Startzeitlimit dauert, kann der Arbeitsprozess beendet werden.
Antwort4
Die Antwort ist, Siedürfenverhindern, dass der AppPool jemals wiederverwendet wird, aber Siesollte nicht.
Der Grund hierfür ist, dass bei einem Speicherverlust irgendwann der gesamte Arbeitsspeicher des Servers verbraucht wird und Windows einen Bluescreen anzeigt oder Ausnahmen wegen unzureichendem Arbeitsspeicher ausgibt, die andere Sites auf demselben IIS-Server zum Absturz bringen.
Entscheiden Sie also, wie viel Speicher von dieser Site verwendet werden darf, und legen Sie die obigen Einstellungen so fest, dass bei Erreichen dieses Limits ein Recycling erfolgt.
Normalerweise erfolgt das Recycling reibungslos, sodass die Endbenutzer nichts davon bemerken. Wenn Sie jedoch Blazor Server verwenden, werden alle Sitzungen auf dem Server ausgeführt und alle Status gehen verloren. In der Praxis sehe ich, dass eine Blazor-App während des Recyclings etwa 5 Sekunden lang die Meldung „Verbinden …“ anzeigt. Mit anderen Worten: Für serverseitige Blazor-Apps läuft es nicht reibungslos.
Die Moral der Geschichte ist, was bereits zuvor erwähnt wurde: Stellen Sie sicher, dass Ihre Site keinen Speicher verliert. Testen Sie Ihren Speicher früh im Entwicklungsprozess, warten Sie nicht, bis er live geht, da Blazor Server speicherintensiv ist und ich aus Erfahrung ziemlich viel Zeit mit der Fehlerbehebung bei Speicherproblemen verbringen musste. Dies ist kein Fehler von Blazor, es liegt einfach in der Natur von Blazor Server-Apps, dass sie sehr kompakten Code erfordern. Früher in .net habe ich mir nie Sorgen um den Speicher gemacht, da der GC das alles erledigt hat, aber die Ausführung innerhalb von IIS ist eine andere Geschichte.