2015-08-11 10 views
8

Abbiamo un'applicazione Web .net ospitata su IIS 7.5. In precedenza questa applicazione era in esecuzione su un pool di applicazioni a 32 bit, ma qualche tempo fa siamo passati al pool di applicazioni a 64 bit.Le sessioni vengono uccise dopo breve tempo nel pool di applicazioni a 64 bit

Recentemente gli utenti hanno iniziato a lamentarsi del fatto che dopo 1-2 minuti di inattività la loro sessione viene uccisa, cosa che abbiamo confermato oggi.

Nel file web.config il timeout della sessione è impostato su 60 minuti. Abbiamo anche notato nel task manager che il processo w3wp per questa applicazione consuma circa 2-2,4 GB di memoria, quindi forse il problema è che il pool di applicazioni sta tentando di riciclare un po 'di memoria?

Il riciclaggio è impostato su periodi di tempo limitati 21:00 e 04:00

Quale potrebbe essere la ragione di questo problemi con sessioni?

EDIT:

Ho controllato alcuni contatori e fatto il dump della memoria di base analizzare, ma non vedo alcun problema.

Permfon data

Nella discarica eeheap analizzare vedo solo la generazione 2 oggetti circa 10-30MB per ogni mucchio e ho 24 di loro

Heap 0 (0000000003083a90) generazione 0 inizia alle 0x00000000fff568b8 generazione 1 inizia a 0x00000000ffa6acf0 generazione 2 inizia a contesto assegnazione 0x00000000ff471000 effimero segmento: nessuna segmento cominciano assegnati dimensione 00000000ff470000 00000000ff471000 00000000ffff8de0 0xb87de0 (12.090.848) Grande mucchio oggetto dalle ore 0x00000006ff471000 segmento iniziano allocato dimensioni 00000006ff470000 00000006ff471000 00000006ff7495c8 0x2d85c8 (2.983.368) heap formato: formato: 0xe60 3a8 (15074216) byte.

Heap 1 generazione (00000000030889c0) 0 inizia alle 0x000000013fc36ed8 generazione 1 a partire 0x000000013f949348 generazione 2 inizia al contesto assegnazione 0x000000013f471000 effimero segmento: nessuna segmento cominciano dimensione allocata 000000013f470000 000000013f471000 000000014035e7b8 0xeed7b8 (15.652.792) Grande mucchio oggetto dalle ore 0x0000000703471000 segmento iniziano allocati dimensione 0000000703470000 0000000703471000 00000007035c5d58 0x154d58 (1396056) Dimensione heap: Dimensione: 0x1042510 (17048848) byte.

EDIT: 2015-08-19 09:00 Quelli sono i contatori per 09:00 2015-08-19

Quello che mi preoccupa è il motivo per cui la memoria in task manager mostra 2,5GB quando il I byte in tutti gli heap mostrano solo circa 100 MB e perché i byte privati ​​(216 MB) sono più grandi dei byte in tutti gli heap? Il carico in questo momento attuale è di circa 40 utenti su questo server.

PERFMON AT 2015-08-19 09:00

EDIT 2015-08-19 14:09

Dopo qualche tempo vedo che ci potrebbe essere un problema con assiemi. Come posso verificarlo con windbg quando sono su .NET 4.5 dove non c'è il comando! Dda?

PERFMON ASSEMBLIES

+0

Avete un codice non gestito? –

+0

Stai ospitando il sito in un'infrastruttura con carico bilanciato? Stai usando le sessioni InProc o Sql? – nimeshjm

+0

Penso che non ci sia alcun codice non gestito in questa applicazione. Per quanto riguarda l'infrastruttura con carico bilanciato, stiamo utilizzando la funzione di default di Windows con due server che ospitano questa applicazione. Sì, la modalità sessione è InProc. – shin

risposta

0

Prova copiare l'applicazione in esecuzione a un pool diverso, ma in questo nuovo disabilitare tutte le assemblee/riferimenti che non avete bisogno, per vedere che cosa sta facendo questo.

Come hai detto, penso che un assemblatore stia bloccando il pool di applicazioni, forse perché forse non supporta 64 bit.

Provare a disabilitare tutti i riferimenti che non si utilizzano, aggiornare tutto, ecc.

Problemi correlati