Ho trovato recentemente alcuni job che fallivano in un Veeam repository server. Il messaggio di errore era il seguente:
Error: Client error: Cannot allocate memory for an array. Array size: [4198400].
Dopo alcuni controlli, era emersa una situazione strana: la somma della memoria utilizzata da tutti i processi presenti in task manager era bel al di sotto della RAM disponibile (6 Gb in questo caso), ma nonostante ciò il tab summary del Task Manager indicava il completo utilizzo di tutta la RAM disponibile.
Il problema in realtà, è che non è possibile vedere tutto il consumo di ram dal Task Manager. Abbiamo bisogno di uno strumento miglior, e quando si tratta di analizzare a fondo un sistema Windows, non c’è niente di meglio di un tool Sysinternal! Nella mia situazione, lo strumento più adatto si è rivelato RamMap:
Nel primo tab, ho potuto verificare “come” la memoria venisse consumata quasi completamente, e quale tipo di “Usage” la stesse usando. Come già notato con Task Manager, c’erano molti processi legati a Veeam, ma nessuno consumava un grande quantitativo di ram:
Nel primo Tab tuttavia c’era già un suggerimento di costa stesse accadendo: 1.5 Gb consumati da Mapped Files. Aprendo il Tab “File Summary” il problema si è evidenziato e spiegato da solo:
Un singolo job di backup, configurato per essere eseguito in reverse incremental, si stava “mangiando” da solo 1.4 Gb. Il problema in sè non è tanto il job di backup, ma Windows 2008 R2 che alloca troppa memoria al servizio Disk Cache per gestire questo file.
Anche se Microsoft ha assicurato che il Dynamic Cache service non è più necessario con Windows 2008 R2 (potete leggere la spiegazione qui), i sintomi erano gli stessi descritti per questo servizio “non più necessario”.
Per risolvere il problema, un’altro tool Sysinternals è venuto in mio aiuto: CacheSet. Questo programma permette di verificare gli attuali valori di cache, pulire la cache stessa e impostare dei limiti inferiori in modo che Windows 2008 non possa consumare tutta quella memoria:
Come potete vedere, il valore di picco della cache è arrivato fino a 4 Gb. Ho impostato un nuovo massimo di 1.5 Gb, e ho inoltre pulito completamente la cache una volta cambiato il parametro. Appena CacheSet ha concluso le riconfigurazioni, il consumo complessivo di memoria sul server è sceso a 4.5 Gb, lasciando sul server 1.5 Gb di RAM libera:
Se dovete dimensionare un Veeam repository, tenete in considerazioni questo comportamento, e dimensionate la memoria del server opportunamente. Specialmente se andrete a usare il Reverse Incremental, il repository server deve aprire sia il file VBK originario che il file VRB per iniettare i blocchi modificati nel primo e scrivere le differenze nel secondo. Questa attività richiede parecchio I/O, ma consuma anche RAM. Più grande è il backup set, maggiore sarà la cache necessaria.
Organizzatevi opportunamente.