Set20200820 Settembre 200828 Gennaio 20140 Commentidi Ermanno Goletto

Backup Exec e occupazione anomala di memoria

Analizzando un sistema con Exchange 2007 e l’Agent di Backup Exec in ambiente Windows 2003 R2 X64 ho visto da Task manager che il PF Usage assumeva valori elevati.

Innanzitutto va detto che in in Windows XP e Windows Server 2003 il PF Usage indica il potenziale utilizzo del page file, non il corrente utilizzo del page file. In altre parole è l’ammontare dei Committed Bytes che misura la richiesta di memoria virtuale ovvero i bytes allocati dai processi per cui il sistema operativo ha predisposto un RAM page frame una page slot nel page file (o forse entrambi). Quando i Committed Bytes superano il valore della RAM disponibile il paging cresce e la dimensione del page file viene viene aumentata con conseguenze sulle performance.

Nel mio caso il PF Usage si aggirava intorno alla dimensione impostata per il page file + la dimensione della RAM segno evidende di memory leak.

Il secondo passo è quello di capire quale sia il processo affetto da un memory leak e anche in questo caso il Task manage può tornare utile, si noti però che la scheda Process visualizza la colonna Mem usage che rappresenta il Working Set ovvero la somma delle pagine di memoria private e delle pagine che il processo condivide con altri processi, queste però sono tutte pagine nella RAM fisica ovvero non nel page file di conseguenza non danno un’indicazione del fatto che il processo abbia fatto una massiccia richiesta di memoria virtuale. Tra l’altro Le pagine di memoria condivise vengono conteggiate per ciascun processo quindi la somma dei Mem Usage di ogni processo è superiore alla memoria realmente occupata inoltre un alto Mem Usage potrebbe anche significare che il processo usa pocamemoria e fa un alto uso di DLL già in uso da altri processi.

Nel Task manager è possibile aggiungere la visualizazione della colonna VM Size nella scheda Process (che corrisponde al Private Bytes del Process Explorer e al Commit Size del Task Manager di Vista). Il VM Size rappresenta la somma delle pagine private in RAM e sul file di paging ovvero le pagine allocate e private del processo, quindi non condivise in altre parole è il valore che indica il consumo di memoria del processo.

Nel mio caso beremote.exe era il processo col valore più elevato segno che è il responsabile del memory leak.

In ogni caso per fugare ogni dubbio è possibile utilizzare il Performance Monitor per visualizzare i valori dei conter:

Process: Private Bytes che indica la memoria esclusiva allocata da processo in esame che non può essere condivisa con altri processi.
Process: Virtual Bytes che indica la dimensione corrente dello spazio di indirizzamento usato dal processo.

E nel mio caso questo è stato il risultato:

Dopo avere riavviato il servizio Remote Agent Service responsabile del processo beremote.exe la situazione è decisamente migliorata:

A questo punto dal momento che non c’erano più dubbi della “colpevolezza” dell’Agent di Backup Exec una ricerca in merito a possibili bug mi ha portato a questo articolo della KB di Symantec Beremote.exe may take an excessive amount of memory on the Exchange server while running Granular Restore Technology (GRT) enabled backups to tape da cui:

“Each time a GRT backup of an Exchange server is performed, the memory used by the Backup Exec Remote Agent for Windows Servers ( RAWS ) process, beremote.exe, may increase. In this situation, the memory used by beremote.exe does not drop back down after backup but continues to rise with each mailbox backup performed.”

Il workaround proposto è il riavvio del servizio tramite la scedulazione di uno script del tipo:

@echo off
echo stopping Remote Agent Service
net stop “BackupExecAgentAccelerator”
@echo off
echo starting Remote Agent Service
net start “BackupExecAgentAccelerator”

Per ulteriori informazioni si vedano:

Articolo successivo

Articolo precedente