Vraag Wat moet ik doen om ervoor te zorgen dat IIS mijn applicatie niet recycleert?


Ik heb een WCF-serviceapp die wordt gehost in IIS. Bij het opstarten gaat het en haalt het een erg dure (in termen van tijd en cpu) bron om te gebruiken als lokale cache.

Helaas lijkt IIS het proces vrij regelmatig te recyclen. Dus ik probeer de instellingen in de Application Pool te wijzigen om ervoor te zorgen dat IIS de applicatie niet recycleert. Tot nu toe heb ik het volgende gewijzigd:

  • Limiet Interval onder CPU van 5 naar 0.
  • Idle Time-out onder Process Model van 20 tot 0.
  • Regelmatig tijdsinterval onder Recycling van 1740 tot 0.

Zal dit genoeg zijn? En ik heb specifieke vragen over de items die ik heb gewijzigd:

  1. Wat betekent specifiek de limiet-intervalinstelling onder CPU? Betekent dit dat als een bepaald CPU-gebruik wordt overschreden, de groep van toepassingen wordt gerecycled?
  2. Wat betekent "gerecycleerd" precies? Is de applicatie volledig afgebroken en opnieuw opgestart?
  3. Wat is het verschil tussen "Worker Process shutdown" en "Application Pool recycling"? De documentatie voor de Idle Time-out onder Process Model gaat over het afsluiten van het werkproces. In de documenten voor regulier tijdsinterval onder recycling wordt gesproken over recycling van toepassingsgroepen. Ik maak niet echt het verschil tussen de twee. Ik dacht dat het w3wp.exe het werkproces is dat de groep van toepassingen uitvoert. Kan iemand het verschil tussen de twee uitleggen over de toepassing?

De reden voor het hebben van IIS7- en IIS7.5-tags is omdat de app in beide wordt uitgevoerd en ik hoop dat de antwoorden tussen de versies hetzelfde zijn.

Afbeelding voor referentie: enter image description here


70
2017-11-22 23:29


oorsprong


Waar kreeg je die screenshot hierboven met de instellingen voor IIS? - Andrew William Ross


antwoorden:


recycling

Recycling is meestal * waarbij IIS een nieuw proces opstart als een container voor uw toepassing en vervolgens de oude geeft aan ShutdownTimeLimit om zijn eigen wil te verliezen voordat deze wordt vermoord.

* - meestal: zie DisallowOverlappingRotation / "Disable overlapped recycle" instelling

Het is vernietigend, in die zin dat het oorspronkelijke proces en al zijn toestandsinformatie worden weggegooid. Het gebruik van de out-of-process-sessiestatus (bijv. State Server of een database, of zelfs een cookie als uw staat klein is) kan u toestaan ​​dit te omzeilen.

Maar het is standaard overlapt - wat betekent dat de duur van een storing wordt geminimaliseerd omdat het nieuwe proces start en is aangesloten op de wachtrij, voordat de oude wordt verteld "u hebt [ShutdownTimeLimit] seconden om weg te gaan.

instellingen

Op uw vraag: alle instellingen op die pagina regelen recycling op de een of andere manier. "Shutdown" kan worden omschreven als "proactieve recycling" - waarbij het proces zelf beslist dat het tijd is om te gaan en op een ordentelijke manier wordt afgesloten.

Reactieve recycling is waar WAS een probleem detecteert en het proces afschiet (na het vaststellen van een geschikte vervangende W3WP).

Hier zijn enkele dingen die kunnen leiden tot het recyclen van de ene vorm of een andere:

  • een ISAPI die beslist dat het ongezond is
  • elke module crasht
  • idle timeout
  • cpu-beperking
  • eigenschappen van app-pools aanpassen
    • als je moeder mei op een gegeven moment geschreeuwd: "Stop pluk of het zal nooit beter worden! "
  • "ping" -fout * niet per se pingen, omdat het een named pipe gebruikt - meer "life detection"
  • alle instellingen in de bovenstaande schermafbeelding

Wat te doen:

Over het algemeen:

  • onbruikbaar maken Niet-actieve time-outs. 20 minuten inactiviteit = boem! Nieuw proces bij de volgende inkomende aanvraag. Zet dat op nul.

  • onbruikbaar maken Regelmatig tijdsinterval - de 29 uur durende standaard is door verschillende partijen omschreven als "krankzinnig", "irritant" en "slim". Eigenlijk zijn slechts twee daarvan waar.

  • Optioneel Aanzetten DisallowRotationOnConfigChange (bovenstaande, Schakel Reycling uit voor configuratiewijzigingen) als je gewoon niet kunt stoppen ermee te spelen - hiermee kun je elke instelling van de app-pool wijzigen zonder dat het direct naar de werkprocessen signaleert dat het moet worden gedood. U moet de app-pool handmatig recyclen om de instellingen van kracht te laten worden, waarmee u instellingen vooraf kunt instellen en vervolgens een wijzigingsvenster kunt gebruiken om ze toe te passen via uw recyclageproces.

  • Als een algemeen principe, het verlof pingen ingeschakeld. Dat is uw vangnet. Ik heb mensen het uit zien zetten en de site blijft soms eindeloos hangen, wat leidt tot paniek ... dus als de instellingen te agressief zijn voor je ogenschijnlijk-zeer-erg-traag reagerende app, maak je een beetje een back-up van ze en zie wat je krijgt, in plaats van het uit te zetten. (Tenzij je een automatische crash-modus dumping hebt ingesteld voor gehangen W3WP's via je eigen monitoringproces)

Dat is genoeg om een ​​goed gedragen proces voor altijd te laten leven. Als het sterft, zeker, zal het worden vervangen. Als het vastloopt, zou pingen dat moeten oppikken en een nieuwe moet binnen 2 minuten starten (standaard; worst-case calc zou moeten zijn: tot ping frequentie + ping time-out + opstarttijdlimiet voordat verzoeken opnieuw beginnen te werken).

CPU-beperking is dat niet normaal gesproken interessant, omdat het standaard is uitgeschakeld en het ook is geconfigureerd om sowieso niets te doen; als het is geconfigureerd om het proces te beëindigen, is dat zeker een trigger voor hergebruik. Laat het maar staan. Opmerking voor IIS 8.x, CPU-throttling wordt ook een optie.

Een (IIS) AppPool is geen (.Net) AppDomain (maar kan een / enkele bevatten)

Maar ... dan komen we terecht op .Net-land en AppDomain-recycling, wat ook een verlies van staat kan veroorzaken. (Zien: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)

Korte versie, doe dat door een web.config-bestand aan te raken in je inhoudsmap (opnieuw met het kiezen!), Of door een map in die map te maken, of een ASPX-bestand, of .. andere dingen ... en dat is wat betreft net zo destructief als een recycle van een app-pool, minde opstartkosten van de native code (het is puur een managed code (.Net) -concept, dus alleen gemanaged code-spul gebeurt hier).

Antivirus kan dit ook activeren tijdens het scannen van web.config-bestanden, waardoor een wijzigingsmelding wordt veroorzaakt, waardoor ....


92
2017-11-23 05:07





Controleer alstublieft,

Waarom recyclen we onze applicatiepools?

als u op internet surft om de reden te vinden waarom groepen van toepassingen zijn geconfigureerd om periodiek automatisch te recyclen, je zult moeilijk worden ingedrukt om een ​​redelijk antwoord te vinden dat niet op geheugenproblemen betrekking heeft. Het is net of de gemeenschap in het algemeen het feit dat onze webapplicaties zo goed zijn geaccepteerd (of servicelagen gehost in IIS) moeten worden gerecycled om geheugenproblemen te voorkomen.

Ik ben altijd van mening geweest dat als je code periodiek opnieuw moet worden opgestart om correct te blijven werken, is er duidelijk iets mis. Er is een bug in je code ergens en dat moet je repareren, in plaats van het proces af en toe opnieuw op te starten om het probleem 'weg te laten gaan'.

Moet echt meer gaan focussen op geheugen management in .NET en om ervoor te zorgen dat onze applicaties zonder problemen kunnen blijven werken.


2
2017-11-19 08:03



Een reden was dat .NET afzonderlijke heap gebruikt voor 'grote objecten' (meestal 85K of groter of iets dergelijks) die niet is gecomprimeerd wanneer garbage collection plaatsvindt (hoewel in .NET 4.5.1 Ik denk dat ze een optie hebben toegevoegd voor het comprimeren van de LOH), en in ASP.NET bij het renderen van HTML aan de serverkant is het niet ongebruikelijk om 85K HTML te zien (vooral voor herhaalde inhoud zoals tabellen en rasters) en deze HTML is eigenlijk op één punt slechts een enorm String-object op de server, en als het in aanmerking komt als een groot object, draagt ​​het bij aan grote fragmentatie van objecten, uiteindelijk resulterend in OutOfMemoryException, vandaar recycling - nothingisnecessary


Gebaseerd op het OP-scenario (lange initialisatie bij opstarten / opwarmen), is nog een ding om te controleren Opstarttijdlimiet (seconden) met een standaardwaarde van 90 seconden. Als de initialisatie langer duurt dan de starttijdlimiet, kan het werkproces worden beëindigd.


0
2017-08-29 07:59