же тест на два идентичных SQL сервера приводят к различному количеству IO объема

Question

Обзора

У меня есть два сервера с теми же аппаратными спецификациями и должен быть настроен одинаково. Они работают под управлением Windows Server 2012 R2 с 8 ядрами и 128 ГБ оперативной памяти. На каждом сервере я запускаю экземпляр Hyper-V SQL Server 2014. Эти серверы в настоящее время ничего не делают.

Проблема

Когда я запускаю тест на каждом сервере, например:

BULK INSERT LOADTEST_01 FROM 'E:\loadtest\data.dat' WITH (DATAFILETYPE='native', BATCHSIZE=100000) 

Один сервер всегда примерно в два раза медленнее (3 минуты против 6 минут). Фактическая производительность с точки зрения пропускной способности одинакова, но «медленный» SQL-сервер генерирует примерно вдвое больше ввода-вывода (считывает и записывает в .mdf и .ldf), что приводит к тому, что тест занимает больше времени для завершения ,

запрос, используемый, чтобы вытащить метрик:

SELECT 
[ReadLatency] = 
    CASE WHEN [num_of_reads] = 0 
     THEN 0 ELSE ([io_stall_read_ms]/[num_of_reads]) END, 
[WriteLatency] = 
    CASE WHEN [num_of_writes] = 0 
     THEN 0 ELSE ([io_stall_write_ms]/[num_of_writes]) END, 
[Latency] = 
    CASE WHEN ([num_of_reads] = 0 AND [num_of_writes] = 0) 
     THEN 0 ELSE ([io_stall]/([num_of_reads] + [num_of_writes])) END, 
[AvgBPerRead] = 
    CASE WHEN [num_of_reads] = 0 
     THEN 0 ELSE ([num_of_bytes_read]/[num_of_reads]) END, 
[AvgBPerWrite] = 
    CASE WHEN [num_of_writes] = 0 
     THEN 0 ELSE ([num_of_bytes_written]/[num_of_writes]) END, 
[AvgBPerTransfer] = 
    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, 
LEFT ([mf].[physical_name], 2) AS [Drive], 
DB_NAME ([vfs].[database_id]) AS [DB], 
[mf].[physical_name] 
FROM 
sys.dm_io_virtual_file_stats (NULL,NULL) AS [vfs] 
JOIN sys.master_files AS [mf] 
ON [vfs].[database_id] = [mf].[database_id] 
AND [vfs].[file_id] = [mf].[file_id] 
-- WHERE [vfs].[file_id] = 2 -- log files 
-- ORDER BY [Latency] DESC 
-- ORDER BY [ReadLatency] DESC 
ORDER BY [WriteLatency] DESC; 
GO 

И метрики (редактируется в попытке сделать легче читать):

Server DBName Logicalnam fileid Type physical nam    size  num_of_reads num_of_writes io_stall_read_ms io_stall_write_ms IO_Stall_Reads_PCT IO_Stall_Writes_PCt writes_and_reads mb_read mb_write reads_pct write_pct read_bytes_% write_bytes_% 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
sql-01 PPTTemp PPTTemp  1  ROWS C:\DATA\PPTTemp.mdf  5000  117   13099   319    220298   0.1     99.9    13216   6.89 3224.16  0.9  99.1   0.2  99.8 
sql-01 PPTTemp PPTTemp_log 2  LOG C:\DATA\PPTTemp_log.ldf 30131.63 54   223225  240    193244   0.1     99.9    223279   1.14 12942.94 0   100   0   100 
sql-02 PPTTemp PPTTemp  1  ROWS C:\DATA\PPTTemp.mdf  5000  108   7786   279    148597   0.2     99.8    7894    6.59 1920.49  1.4  98.6   0.3  99.7 
sql-02 PPTTemp PPTTemp_log 2  LOG C:\DATA\PPTTemp_log.ldf 40105.25 57   174750  148    54018    0.3     99.7    174807   1.16 10194.92 0   100   0   100 

Я пытался копировать один и тот же SQL Виртуальная машина сервера для обоих физических хост-серверов, но экземпляр на «медленном» сервере продолжает генерировать больше ввода-вывода, а «быстрый» сервер генерирует меньше IO. Те же результаты, если я исключаю членство в сети и в домене.

У кого-нибудь есть идеи?

Я собираюсь полностью удалить все и переустановить, начиная с операционной системы. Я не понимаю, как хост Hyper-V может заставить виртуальную машину SQL Server генерировать больше ввода-вывода, но я в настоящее время не могу придумать ничего другого.

Answer 1

Бьюсь об заклад, ваша модель восстановления и/или начальный размер значений базы данных не идентичны между источником и целью.

Answer 2

Оказалось, что на серверах были разные «системные профили». По какой-то причине серверы пришли из Dell по-разному. Это было обнаружено только после установки программного обеспечения администратора Dell OpenManage Server. Более медленный сервер был настроен на более энергосберегающий системный профиль.