Condividi tramite

Risolvere i problemi di perdita di memoria nativa in un pool di applicazioni IIS 7.x

Si applica a: Internet Information Services 7.0 e versioni successive

Questo articolo illustra come identificare la causa della perdita di memoria nativa in un pool di applicazioni IIS.

Panoramica

È importante tenere presente che è normale per un'allocazione di memoria elevata perché un'applicazione Web gestisce le richieste.

Quando si verifica la perdita di memoria in un pool di applicazioni IIS, l'aumento della memoria fisica (RAM) non è efficace perché la memoria in questo scenario non è la memoria fisica (RAM) ma una memoria virtuale. La tabella seguente riepiloga la memoria virtuale indirizzabile dall'applicazione Web.

Processo Finestre Memoria indirizzabile (con un processo compatibile con indirizzi di grandi dimensioni) Limite pratico per i byte virtuali Limite pratico per byte privati
32 bit 32 bit 2 GB 1.400 MB 800 MB
32 bit 32 bit con /3 GB 3 GB 2.400 MB 1.800 MB
32 bit 64 bit 4 GB 3.400 MB 2.800 MB
64 bit 64 bit 8 TB Non applicabile Non applicabile

Scenario

Vengono visualizzati in modo coerente sia Process\Private Bytes che Process\Virtual Bytes are increasing or Process\Private Bytes and Process\Working Set of w3wp.exe are increasing and Memory\Available Bytes is decrescenti.

Può causare un'eccezione di memoria insufficiente in un pool di applicazioni in IIS.

Per eseguire il ripristino, è necessario riavviare il pool di applicazioni, ma dopo questa operazione, l'utilizzo della memoria torna a un livello elevato. Quando viene visualizzato l'errore precedente, il pool di applicazioni è già stato riavviato automaticamente.

Raccolta dei dati

La prima operazione da eseguire quando si verifica un utilizzo elevato della memoria consiste nel determinare se la memoria di un processo di lavoro in un pool di applicazioni in IIS viene persa o meno. È possibile usare Monitor prestazioni. Per altre informazioni sull'uso di Monitor prestazioni, vedere Analisi dei dati sulle prestazioni.

Suggerimento

Se è necessario identificare il pool di applicazioni associato a un determinato processo di w3wp.exe , aprire un prompt dei comandi amministrativo, passare alla cartella %windir%\System32\inetsrv (cd %windir%\System32\inetsrv) ed eseguire appcmd list wp. Verrà visualizzato l'identificatore del processo (PID) del processo di w3wp.exe tra virgolette. È possibile associare il PID al PID disponibile in Gestione attività.

Dopo aver verificato che un processo di w3wp.exe sta riscontrando un utilizzo elevato della memoria, è necessario due informazioni per determinare la causa del problema.

  • Set di agenti di raccolta dati Monitor prestazioni.
  • Dump della memoria in modalità utente del processo di w3wp.exe .

Entrambi devono essere raccolti dall'utilizzo di memoria insufficiente, ad esempio l'avvio del processo fino all'utilizzo elevato della memoria, ad esempio quando si verifica un'eccezione di memoria insufficiente.

Raccolta di un set di raccolta dati Monitor prestazioni

Monitor prestazioni (Perfmon) i dati possono essere visualizzati in tempo reale oppure possono essere raccolti in un set di agenti di raccolta dati che possono essere esaminati in un secondo momento. Per risolvere un problema di memoria elevata, è necessario raccogliere un set di agenti di raccolta dati. Per creare un set di agenti di raccolta dati per la risoluzione dei problemi di memoria elevata, seguire questa procedura:

  1. Aprire Strumenti di amministrazione da Windows Pannello di controllo.
  2. Fare doppio clic su Monitor prestazioni.
  3. Espandere il nodo Set di agenti di raccolta dati.
  4. Fare clic con il pulsante destro del mouse su User Defined (Definito dall'utente) e selezionare New Data Collector Set (Nuovo>set di raccolta dati).
  5. Immettere Memoria elevata come nome del set di agenti di raccolta dati.
  6. Selezionare il pulsante di opzione Crea manualmente (avanzate).
  7. Seleziona Avanti.
  8. Selezionare il pulsante di opzione Crea log dati.
  9. Selezionare la casella di controllo *Contatore prestazioni.
  10. Seleziona Avanti.
  11. Seleziona il pulsante Aggiungi.
  12. Espandere Processo dall'elenco dei contatori.
  13. Selezionare Byte privati, Byte virtuali e Working Set dall'oggetto Thread.
  14. Selezionare <TUTTE le istanze> dall'elenco delle istanze.
  15. Selezionare Aggiungi.
  16. Espandere Memoria dall'elenco dei contatori.
  17. Selezionare Byte disponibili nell'oggetto Thread .
  18. Selezionare Aggiungi.
  19. Seleziona OK.
  20. Impostare Intervallo di esempio su 1 Secondi e quindi Avanti e Fine.

La finestra di dialogo dovrebbe ora essere simile alla seguente:

Screenshot della finestra di dialogo Proprietà agente di raccolta dati 01. La scheda Contatori delle prestazioni è aperta.

Creazione di una regola di diagnostica di debug 1.2

Il modo più semplice per raccogliere dump del processo in modalità utente quando si verifica una condizione di memoria elevata consiste nell'usare Debug Diagnostics (DebugDiag). È possibile scaricare Debug Diagnostic Tool v2 Update 3.

Installare DebugDiag nel server ed eseguirlo. (Lo troverai sul Menu Start dopo l'installazione.

Le informazioni più importanti per determinare quale funzione ha causato la perdita di memoria è costituita dalle tracce dello stack delle allocazioni dell'heap. Per impostazione predefinita, queste tracce dello stack non vengono acquisite. È possibile abilitare questa funzionalità per processo. Usare il comando seguente per abilitare l'analisi dello stack:

gflags -i w3wp.exe +ust

Il comando non abilita l'analisi dello stack per un processo già in esecuzione. Pertanto, per i processi che non è possibile riavviare (ad esempio, servizi, lsas, Winlogon), è necessario riavviare il computer di test.

Usare i comandi seguenti per verificare quali impostazioni sono state impostate per un processo specifico:

gflags -i w3wp.exe

Quando si esegue DebugDiag, viene visualizzata la finestra di dialogo Seleziona tipo di regola. Seguire questa procedura per creare una regola di perdita per il pool di applicazioni:

  1. Selezionare Native (non-.NET) Memory Handle Leak>Next (Perdita di handle di memoria).>

  2. Selezionare un processo e selezionare Avanti.

  3. Seleziona Configura.

  4. Impostare la regola come illustrato nell'immagine seguente:

    È possibile modificare questi valori, se necessario, ma prestare attenzione a non specificare un numero ridotto di MB per generare le tonnellate di file di dump. Generare un userdump quando i byte privati raggiungono 800 MB e ogni 100 MB aggiuntivo successivamente. Generare un userdump quando i byte virtuali raggiungono 1.024 MB e ogni 200 MB aggiuntivo successivamente.

    Screenshot della finestra di dialogo Configura dump utente per regola di perdita. Vengono selezionate tutte le opzioni.

  5. Selezionare Salva e chiudi.

  6. Seleziona Avanti.

  7. Immettere un nome per la regola se si desidera e prendere nota del percorso in cui verranno salvati i dump. È possibile modificare questa posizione, se necessario.

  8. Seleziona Avanti.

  9. Selezionare Attiva regola ora>fine.

Se si ottiene l'errore di memoria insufficiente anche quando si ottengono i dump della memoria, è possibile ottenere manualmente i dump della memoria.

  1. Selezionare la scheda Processo .
  2. Fare clic con il pulsante destro del mouse sul processo di destinazione.
  3. Selezionare Crea utente completodump.

Analisi dei dati

Dopo aver recuperato l'errore di memoria insufficiente o aver creato i dump della memoria, si avranno due set di dati da esaminare; Set dell'agente di raccolta dati Perfmon e dump della memoria. Per iniziare, esaminare i dati di Perfmon.

Analisi dei dati relativi alle prestazioni

Per esaminare i dati perfmon per il problema, fare clic con il pulsante destro del mouse sul set di agenti di raccolta dati a memoria elevata elencato nel nodo Definito dall'utente e selezionare Report più recente. È possibile visualizzare qualcosa di simile all'immagine seguente:

Screenshot dei dati sulle prestazioni nel set dell'agente di raccolta dati a memoria elevata.

Per accedere alla radice di ciò che causa il problema elevato della CPU, esaminare i dump creati con DebugDiag.

Analisi del dump con DebugDiag

DebugDiag ha la possibilità di riconoscere molti problemi eseguendo un'analisi automatica del dump. Per questo particolare problema, le analizzatore prestazioni di DebugDiag sono adatte per identificare la causa radice del problema elevato della CPU. Per usare l'analizzatore, seguire questa procedura:

  1. Selezionare la scheda Analisi avanzata in DebugDiag.
  2. Selezionare Analizzatori pressione memoria. Assicurarsi di usare MemoryAnalysis.asp anziché DotNetMemoryAnalysis-BETA.asp.
  3. Selezionare Aggiungi file di dati.
  4. Passare al percorso in cui sono stati creati i dump. Per impostazione predefinita, si tratta di una sottocartella della cartella C:\Programmi\DebugDiag\Logs .
  5. Selezionare uno dei dump e quindi premere CTRL+A per selezionare tutti i dump in tale cartella.
  6. Selezionare Apri.
  7. Selezionare Avvia analisi.

DebugDiag richiede alcuni minuti per analizzare i dump e fornire un'analisi. Al termine dell'analisi, viene visualizzata una pagina simile all'immagine seguente:

Screenshot di un report di analisi DebugDiag.

Note

La parte superiore del report indica che la perdita di memoria è stata rilevata. Nel sommario verrà visualizzato un collegamento ai dettagli del report di analisi delle perdite. Selezionare il collegamento e verranno visualizzate informazioni sulle prime 10 moduli in base al numero di allocazioni o alle dimensioni di allocazione. Ecco l'esempio:

Screenshot dei dettagli del modulo con memoria elevata.

Da questa analisi è possibile vedere che il componente leakcom è in esecuzione. Per esaminare ulteriormente le informazioni sul modulo di leakcom, come illustrato di seguito, è possibile vedere che il CFoo::crtheap metodo alloca la memoria in sospeso.

Screenshot dei dettagli per leakcom nel modulo.

Il passaggio successivo consiste nell'esaminare il codice del CFoo::crtheap metodo. A tale scopo, si trova il frammento di codice seguente:

STDMETHODIMP CFoo::crtheap(void)
{
    malloc(1024 * 10);

    return S_OK;
}

Il codice precedente causerà sicuramente una perdita di memoria perché la memoria allocata non viene rilasciata.

Suggerimento

Se si abilita l'analisi dello stack (gflags -i w3wp.exe +ust), è possibile visualizzare lo stack di chiamate seguente analizzando i dump con WinDBG. Lo stack di chiamate seguente non verrà mai visualizzato se si disabilita l'analisi dello stack per impostazione predefinita.

0:000> !heap -p -a 42ae5b28
    address 42ae5b28 found in
    _HEAP @ 6690000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        42ae5b28 0541 0000  [00]   42ae5b40    02800 - (busy)
        77e9df42 ntdll!RtlAllocateHeap+0x00000274
        75133db8 msvcr90!malloc+0x00000079
        513f3cc7 LeakTrack!CCRTMemoryLT::R90mallocDetour+0x00000067
        75933cef oleaut32!CTypeInfo2::Invoke+0x0000023f
        61f527b8 leakcom!ATL::IDispatchImpl::Invoke+0x00000058
        f05cb4d vbscript!IDispatchInvoke+0x00000059
        f053f40 vbscript!InvokeDispatch+0x000001a5
        f060795 vbscript!InvokeByName+0x00000043
        f06080d vbscript!CScriptRuntime::RunNoEH+0x000022cf
        f054122 vbscript!CScriptRuntime::Run+0x00000064
        f054099 vbscript!CScriptEntryPoint::Call+0x00000074
        f054279 vbscript!CSession::Execute+0x000000c8
        f0544c0 vbscript!COleScript::ExecutePendingScripts+0x00000146
        f052013 vbscript!COleScript::SetScriptState+0x0000014d
        513023c0 asp!CActiveScriptEngine::TryCall+0x00000019
        513027b3 asp!CActiveScriptEngine::Call+0x000000e7
        513022c7 asp!CallScriptFunctionOfEngine+0x0000003e
        513063d5 asp!ExecuteRequest+0x0000014a
        51302676 asp!Execute+0x000001c4
        513028f2 asp!CHitObj::ViperAsyncCallback+0x000003fc
        51302030 asp!CViperAsyncRequest::OnCall+0x0000006a
        563de19 comsvcs!CSTAActivityWork::STAActivityWorkHelper+0x00000032
        771304fb ole32!EnterForCallback+0x000000f4
        771284c7 ole32!SwitchForCallback+0x000001a8
        77126964 ole32!PerformCallback+0x000000a3
        7713df32 ole32!CObjectContext::InternalContextCallback+0x0000015b
        771f47ef ole32!CObjectContext::DoCallback+0x0000001c
        563dfbd comsvcs!CSTAActivityWork::DoWork+0x0000012f
        563e51b comsvcs!CSTAThread::DoWork+0x00000018
        563f24d comsvcs!CSTAThread::ProcessQueueWork+0x00000037
        563f4c0 comsvcs!CSTAThread::WorkerLoop+0x00000135
        773a1287 msvcrt!_endthreadex+0x00000044

Conclusione

Usando Perfmon e DebugDiag, è possibile raccogliere facilmente i dati che possono essere utili per determinare la causa della perdita di memoria nei pool di applicazioni. Se non si riesce a trovare la causa radice usando queste tecniche, è possibile aprire un ticket di supporto con Microsoft. Assicurarsi di includere i dati Perfmon e i dump di analisi dello stack nel ticket di supporto per ridurre il tempo di turnaround.

Altre risorse