Una delle novità di SQL Server 2008 è la possibilità di comprimere dati e backup.
La compressione dei dati non è ancora disponibile nella buil distribuita poche settimane fa; è stata annunciata nella CTP6 che uscirà entro qualche mese. Nella CTP5 (aka November CTP) è possibile testare la compressione dei backup e giusto ieri ho fatto qualche test. L'ambiente di prova è stata una virtual machine a cui ho dedicato 800 MB di RAM; la macchina fisica è un processore (single core) Athlon XP 2600 con 1,5 GB di RAM. Risorse modeste, quindi, con le quali non mi aspettavo risultati particolari.
Ho utilizzato per i test un database di 9 GB (8 GB per il file dati + 1 GB per il t-log); un backup non compresso di questo database produce un file di poco più di 6 GB che viene eseguito in poco meno di 5 minuti su di un disco locale; poichè come tutti sappiamo fare un backup sulla stessa macchina dei dati serve a ben poco, ho ripetuto il test eseguendo il backup anche su una risorsa di rete e lo stesso backup (non compresso) impiegava circa 21 minuti.
Stabilita questa "baseline" iniziavo i test usando la compressione. In questo modo il file prodotto era circa il 20% di quello non compresso (1,14 GB contro 6,1 GB) ed anche i tempi di scrittura si rivelavano inferiori: meno di 3 minuti in locale (tra i 2.45 e 2.55) e poco più di 6 minuti (tra i 6.10 e 6.25) eseguendo il backup su una risorsa di rete. Come si vede il vantaggio maggiore si ha quando il backup viene eseguito via rete (e questo era comunque prevedibile) dove le minori dimensioni del file da scrivere consentono di eseguire la medesima attività nel 30% del tempo.
Fin qui le note positive. Quelle negative riguardano l'utilizzo della CPU. Un backup non compresso, nello scenario in cui ho eseguito i miei test, utilizzava tra il 20 e il 30% di CPU, dopo picchi iniziali del 45-50% nei primi secondi dall'avvio del backup; leggermente superiore la potenza di calcolo richiesta (55-60%) nel caso dei backup eseguiti su risorse di rete. Abilitando la compressione l'utilizzo del processore era sensibilmente superiore. La media di utilizzo della CPU era vicina al 75% nel caso di un backup locale (in realtà oscillava tra il 40 e l'80%, ma quasi sempre più vicino ai margini superiori e con picchi iniziali prossimi al 100%). Il backup via rete era più parsimonioso di risorse e richiedeva una media di circa il 40% della CPU con un utilizzo abbastanza lineare (ed un picco iniziale intorno al 60%); evidentemente il rallentamento introdotto dalla scrittura via rete consente di eseguire lo stesso carico di lavoro da parte della CPU ma in maniera meno "stressante".
Tutti i valori riportati sono il frutto di 4 o 5 misurazioni ma nonostante ciò non possono essere considerati in alcun modo dei punti di riferimento e i test andrebbero estesi introducendo diverse variabili al fine di simulare il più possibile uno scenario reale. Se qualcun altro eseguirà dei test simili mi piacerebbe che le esperienze venissero condivise...
Bye