Cosa devo fare per assicurarmi che IIS non ricicli la mia applicazione?

Ho un'app di servizio WCF ospitata in IIS. All'avvio, va e recupera una risorsa davvero costosa (in termini di tempo e CPU) da usare come cache locale.

Sfortunatamente, IIS sembra riciclare il processo su base abbastanza regolare. Quindi sto cercando di modificare le impostazioni nel pool di applicazioni per assicurarmi che IIS non ricicli l'applicazione. Finora ho cambiato quanto segue:

• Intervallo limite sotto CPU da 5 a 0.
• Timeout di inattività in Modello di processo da 20 a 0.
• Intervallo di tempo regolare in Riciclaggio dal 1740 a 0.

Sarà abbastanza? E ho domande specifiche sugli articoli che ho cambiato:

1. Cosa significa in particolare l'impostazione Limite intervallo sotto CPU? Significa che se viene superato un determinato utilizzo della CPU, il pool di applicazioni verrà riciclato?
2. Cosa significa esattamente "riciclato"? L'applicazione è stata completamente demolita e riavviata?
3. Qual è la differenza tra "Arresto del processo di lavoro" e "Riciclo del pool di applicazioni"? La documentazione per il timeout di inattività in Process Model parla della chiusura del processo di lavoro. Mentre i documenti per Intervallo di tempo regolare in Riciclaggio parlano del riciclaggio del pool di applicazioni. Non riesco proprio a capire la differenza tra i due. Pensavo che w3wp.exe fosse il processo di lavoro che esegue il pool di applicazioni. Qualcuno può spiegare la differenza tra le due applicazioni?

Il motivo per avere i tag IIS7 e IIS7.5 è perché l'app verrà eseguita in entrambi e spero che le risposte siano le stesse tra le versioni.

Immagine di riferimento:

Raccolta differenziata

Il riciclaggio di solito è * in cui IIS avvia un nuovo processo come contenitore per l'applicazione, quindi assegna quello precedente a ShutdownTimeLimit per andare via di sua spontanea volontà prima che venga ucciso.

* - di solito: vedi l'impostazione DisallowOverlappingRotation / "Disabilita riciclo sovrapposto"

È distruttivo , in quanto il processo originale e tutte le sue informazioni sullo stato vengono scartate. L'uso di uno stato di sessione out-of-process (ad es. State Server o un database o persino un cookie se il tuo stato è minuscolo) può permetterti di aggirare il problema.

Ma è per impostazione predefinita sovrapposta , il che significa che la durata di un'interruzione è ridotta al minimo perché il nuovo processo si avvia e si collega alla coda delle richieste, prima che a quello precedente venga detto "hai [ShutdownTimeLimit] secondi per andare via. Per favore, rispetta."

impostazioni

Alla tua domanda: tutte le impostazioni su quella pagina controllano il riciclo in qualche modo. "Spegnimento" potrebbe essere descritto come "riciclaggio proattivo" - in cui il processo stesso decide che è il momento di andare ed esce in modo ordinato.

Il riciclaggio reattivo è il punto in cui WAS rileva un problema e avvia il processo (dopo aver stabilito un W3WP sostitutivo adatto).

Ora, ecco alcune cose che possono causare il riciclaggio di una forma o dell'altra:

• un ISAPI che decide che non è salutare
• qualsiasi modulo in crash
• timeout inattivo
• limitazione della CPU
• regolazione delle proprietà del pool di app
  • come la tua mamma potrebbe aver urlato ad un certo punto: "Smettila di raccolta a esso, o non sarà mai stare meglio!"
• errore "ping" * in realtà non esegue il ping di per sé, perché utilizza una pipe denominata - più "rilevamento della vita"
• tutte le impostazioni nello screenshot sopra

Cosa fare:

Generalmente:

• Disabilita i timeout di inattività . 20 minuti di inattività = boom! Nuovo processo alla successiva richiesta in arrivo. Impostalo a zero.

• Disabilita intervallo di tempo regolare : l'impostazione predefinita di 29 ore è stata descritta come "folle", "fastidiosa" e "intelligente" da varie parti. In realtà, solo due di quelli sono veri.

• Facoltativamente, attiva DisallowRotationOnConfigChange (sopra, Disabilita Reycling per le modifiche alla configurazione ) se non riesci a smettere di giocarci - questo ti consente di cambiare qualsiasi impostazione del pool di app senza che segnali istantaneamente ai processi di lavoro che deve essere ucciso. È necessario riciclare manualmente il pool di app per rendere effettive le impostazioni, il che consente di preimpostare le impostazioni e quindi utilizzare una finestra di modifica per applicarle tramite il processo di riciclo.

• Come principio generale, lasciare il ping abilitato . Questa è la tua rete di sicurezza. Ho visto persone spegnerlo, e poi il sito si blocca indefinitamente a volte, portando al panico ... quindi se le impostazioni sono troppo aggressive per la tua app apparentemente molto molto lenta, rispondi un po ' e vedi cosa ottieni, piuttosto che spegnerlo. (A meno che tu non abbia impostato il dumping in modalità crash automatico per i W3WP sospesi attraverso il tuo processo di monitoraggio)

È abbastanza per far vivere per sempre un processo ben educato. Se muore, certo, sarà sostituito. Se si blocca, il ping dovrebbe prendere che e uno nuovo dovrebbe iniziare entro 2 minuti (per impostazione predefinita, nel caso peggiore calc dovrebbe essere: fino a frequenza di ping + ping timeout + limite di tempo di avvio prima che le richieste di iniziare a lavorare di nuovo).

La limitazione della CPU non è normalmente interessante, perché per impostazione predefinita è disattivata ed è anche configurata per non fare nulla; se fosse configurato per terminare il processo, questo sarebbe sicuramente un fattore scatenante del riciclaggio. Lascialo fuori. Nota per IIS 8.x, anche la limitazione della CPU diventa un'opzione.

Un AppPool (IIS) non è un AppDomain (.Net) (ma può contenere uno / alcuni)

Ma ... poi entriamo in .Net land e AppDomain riciclando, il che può anche causare una perdita di stato. (Vedi: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/ )

Versione breve, lo fai toccando un file web.config nella cartella del contenuto (di nuovo con il prelievo!), O creando una cartella in quella cartella, o un file ASPX, o ... altre cose ... e questo è tutto distruttivo come un riciclo del pool di app, meno i costi di avvio del codice nativo (è puramente un concetto di codice gestito (.Net), quindi qui si verificano solo elementi di codice gestito).

L'antivirus può anche attivare questo mentre scansiona i file web.config, causando una notifica di modifica, causando ....

Gentilmente controlla,

Perché ricicliamo i nostri pool di applicazioni?

se si naviga sul Web per trovare il motivo per cui i pool di applicazioni sono configurati per il riciclo automatico periodico, sarà difficile trovare una risposta ragionevole che non riguardi problemi di memoria. È come se la comunità in generale avesse praticamente accettato il fatto che le nostre applicazioni Web (o livelli di servizio ospitati in IIS) dovranno essere riciclate per evitare problemi di memoria.

Sono sempre stato dell'opinione che se il tuo codice richiede riavvi periodici per continuare a funzionare correttamente, allora qualcosa è chiaramente sbagliato. C'è un bug nel tuo codice da qualche parte e devi risolverlo, invece di riavviare il processo di tanto in tanto per far "sparire" il problema.

È davvero necessario iniziare a concentrarsi maggiormente sulla gestione della memoria in .NET e assicurarsi che le nostre applicazioni possano continuare a funzionare senza problemi.

In base allo scenario OP (lunga inizializzazione all'avvio / riscaldamento), un'altra cosa da controllare è il limite del tempo di avvio (secondi) che ha un valore predefinito di 90 secondi. Se l'inizializzazione richiede più del limite di tempo di avvio, è possibile terminare il processo di lavoro.