none
SQL 2017 - Formattazione volumi RRS feed

 > 

  • Domanda

  • Question
    Registrati per votare
    0
    Registrati per votare

    Buongiorno a tutti,

    da qualche giorno ho installato una nuova Virtual Machine Win2019 (8vCPU e 64GB di RAM) con a bordo SQL con circa 60 DB per un peso totale, tra DATA e LOGS, pari a 1TB

    Per l'installazione SQL 2017, ho separato il disco C:\ per il sistema operativo e files binari di SQL; Disco E:\ per i database, Disco F:\ per i LOG, Disco G:\ per TempDB

    La nuova Virtual Machine è su un Cluster Hyper-V 2016 con collegati volumi SSD 15k in SAN, tramite FC, condivisi nel Cluster in CSV; volume di dimensione 1.2TB, formattato 64k GPT, dedicato interamente alla VM.

    Però mi sono accorto di aver commesso una grave, gravissima leggerezza; i volumi VHDX dedicati ad SQL DATA, LOG e TempDB non sono stati formattati a 64k come riportato nei documenti di Best Practices; quindi la formattazione NTFS è 4K

    Vi chiedo, anche in base alle vostre esperienze, quanto inciderà sulle prestazioni future, in quanto già sono attivi JOB ETL di caricamento-dati massivi verso i DB SQL.

    Trattandosi di volumi in SAN SSD 15k, quindi di Tier pregiato, vale la pena ri-formattare i volumi a 64k? Ovviamente pianificando un fermo tecnico, spostare momentaneamente i dati e log e rimettere il tutto com'era.

    Il mea culpa è d'obbligo!

    Grazie a tutti per il supporto tecnico.

    Buona giornata

    domenica 23 gennaio 2022 10:15
    |

Risposte

  • Question
    Registrati per votare
    0
    Registrati per votare

    Vi chiedo, anche in base alle vostre esperienze, quanto inciderà sulle prestazioni future, in quanto già sono attivi JOB ETL di caricamento-dati massivi verso i DB SQL.

    Ciao,

    è una "magra consolazione" ma è successo anche a me :) il server non era ancora in produzione e ho potuto ri-formattare.

    Non ho avuto occasione di fare test comparativi sullo stesso HW con e senza stripe-unit size impostata a 64K, sicuramente una singola operazione di I/O eseguita si trasforma in più operazioni di I/O se la richiesta attraversa i confini di una o più unità di stripe. L'effetto cumulativo di queste operazioni multiple di I/O contribuisce al degrado delle prestazioni.. il quanto non l'ho misurato ma è anche funzione del carico di lavoro.

    Ho recuperato da questo articolo il seguente case study..

    Potresti vedere se le prestazioni sono buone anche con la stripe impostata a 4K e poi prendere la decisione finale.

    Un consiglio, se puoi, imposta anche la Instant File Initialization se non l'hai già fatto (e puoi farlo) compensi :)

    Ciao!

    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn



    domenica 23 gennaio 2022 11:14
    |
    Moderatore

Tutte le risposte

  • Question
    Registrati per votare
    0
    Registrati per votare

    Vi chiedo, anche in base alle vostre esperienze, quanto inciderà sulle prestazioni future, in quanto già sono attivi JOB ETL di caricamento-dati massivi verso i DB SQL.

    Ciao,

    è una "magra consolazione" ma è successo anche a me :) il server non era ancora in produzione e ho potuto ri-formattare.

    Non ho avuto occasione di fare test comparativi sullo stesso HW con e senza stripe-unit size impostata a 64K, sicuramente una singola operazione di I/O eseguita si trasforma in più operazioni di I/O se la richiesta attraversa i confini di una o più unità di stripe. L'effetto cumulativo di queste operazioni multiple di I/O contribuisce al degrado delle prestazioni.. il quanto non l'ho misurato ma è anche funzione del carico di lavoro.

    Ho recuperato da questo articolo il seguente case study..

    Potresti vedere se le prestazioni sono buone anche con la stripe impostata a 4K e poi prendere la decisione finale.

    Un consiglio, se puoi, imposta anche la Instant File Initialization se non l'hai già fatto (e puoi farlo) compensi :)

    Ciao!

    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn



    domenica 23 gennaio 2022 11:14
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    Buongiorno Sergio,

    grazie per la cortese risposta.

    Ora, raccolgo il tuo consiglio ed abilito Instant File Initialization

    Un'altro particolare, purtroppo; i tecnici che hanno installato i nuovi dischi SSD da 15k sullo storage, hanno realizzato un aggregato in RAID5.

    Leggevo che RAID5 non è proprio indicato per le performance in scrittura, o sbaglio?

    Non a caso il Case Study è su HD SAS 15k in RAID10, che raccoglie le esigenze di Read e Write.

    Fammi sapere cosa ne pensi del RAID5

    Grazie ancora per il supporto

    domenica 23 gennaio 2022 12:28
    |
  • Question
    Registrati per votare
    0
    Registrati per votare


    Leggevo che RAID5 non è proprio indicato per le performance in scrittura, o sbaglio?

    E' esattamente così, RAID 5 fornisce ottime prestazioni sulle operazioni di lettura e performance non ottimali per le operazioni di scrittura.

    Un RAID 10 garantisce ottime performance anche su operazioni di scrittura. Al limite si potrebbe utilizzare un volume RAID 5 per i file dati mdf, ndf ed un RAID 10 per transaction log e tempdb. Il tempdb dovrebbe essere sempre posizionato sul volume più veloce.

    Ovviamente tutto è relativo al carico di lavoro che è necessario supportare e al livello attuale delle performance.

    Se hai un aggregato RAID 5.. hai un altro buon motivo per rifare la macchina :)

    Fammi sapere cosa deciderete di fare.

    A presto!

    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn



    martedì 25 gennaio 2022 17:38
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    Buonasera Sergio,

    grazie ancora per la cortese risposta.

    Non ho alternative, o rifaccio la VM o creo nuovi volumi sulla stessa VM formattati 64k, spostando successivamente i file DB e LOGS; purtroppo lato Storage l'aggregato RAID5 non posso rifarlo :(

    Anzi, in SSD ho anche un aggregato RAID1 e un altro RAID6, ma non credo di migliorare molto spostando solo le VM.

    Ti faccio sapere.

    Grazie ancora per il supporto


    • Modificato SysAdmin_IT mercoledì 26 gennaio 2022 13:09
    mercoledì 26 gennaio 2022 13:09
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    Ciao,

    concordo con te che lo spostamento delle sole VM (sistema operativo, applicazioni, ecc..) non migliorerà di molto lo scenario.

    A questo punto io mi concentrerei sulla possibilità di spostare file dati e log (alla peggio anche solo i log) su un volume RAID1 o RAID10.

    Per curiosità, sarebbe interessante eseguire questa query prima e dopo l'operazione, ovviamente dopo almeno una settimana di esecuzione di un carico di lavoro significativo senza spegnimenti del servizio SQL Server.

    -- Drive level latency information (Query 26) (Drive Level Latency)
-- Based on code from Jimmy May
SELECT tab.[Drive], tab.volume_mount_point AS [Volume Mount Point], 
	CASE 
		WHEN num_of_reads = 0 THEN 0 
		ELSE (io_stall_read_ms/num_of_reads) 
	END AS [Read Latency],
	CASE 
		WHEN io_stall_write_ms = 0 THEN 0 
		ELSE (io_stall_write_ms/num_of_writes) 
	END AS [Write Latency],
	CASE 
		WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
		ELSE (io_stall/(num_of_reads + num_of_writes)) 
	END AS [Overall Latency],
	CASE 
		WHEN num_of_reads = 0 THEN 0 
		ELSE (num_of_bytes_read/num_of_reads) 
	END AS [Avg Bytes/Read],
	CASE 
		WHEN io_stall_write_ms = 0 THEN 0 
		ELSE (num_of_bytes_written/num_of_writes) 
	END AS [Avg Bytes/Write],
	CASE 
		WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
		ELSE ((num_of_bytes_read + num_of_bytes_written)/(num_of_reads + num_of_writes)) 
	END AS [Avg Bytes/Transfer]
FROM (SELECT LEFT(UPPER(mf.physical_name), 2) AS Drive, SUM(num_of_reads) AS num_of_reads,
	         SUM(io_stall_read_ms) AS io_stall_read_ms, SUM(num_of_writes) AS num_of_writes,
	         SUM(io_stall_write_ms) AS io_stall_write_ms, SUM(num_of_bytes_read) AS num_of_bytes_read,
	         SUM(num_of_bytes_written) AS num_of_bytes_written, SUM(io_stall) AS io_stall, vs.volume_mount_point 
      FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
      INNER JOIN sys.master_files AS mf WITH (NOLOCK)
      ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id
	  CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.[file_id]) AS vs 
      GROUP BY LEFT(UPPER(mf.physical_name), 2), vs.volume_mount_point) AS tab
ORDER BY [Overall Latency] OPTION (RECOMPILE);

-- Shows you the drive-level latency for reads and writes, in milliseconds
-- Latency above 20-25ms is usually a problem

    Ciao


    Sergio Govoni

    Microsoft Data Platform MVP | MVP Profile | English Blog | Twitter | LinkedIn


    sabato 29 gennaio 2022 07:35
    |
    Moderatore
  • Question
    Registrati per votare
    0
    Registrati per votare

    Buonasera Sergio,

    grazie per l'ulteriore dettaglio.

    Intanto posso inviate l'output della query, eseguita poco fa

    Poi vediamo dopo il move, ancora da pianificare.

    Ci aggiorniamo



    lunedì 31 gennaio 2022 15:53
    |