MS SQL Server расчет производительности

Часто возникает вопрос- какую нагрузку можно дать на конкретный MS SQL Server?

Он 10 мегабайт в минуту прочтет? А 100 мегабайт? А 1 гигабайт?

 

Есть хитрые процедуры, в данном случае приводится статистика по тестовой среде. 4 Gb сервер, SATA диск. Специфика такова, что рассчитываются варианты для случаев максимальных задержек по чтению не более 60 секунд в минуту. Фактически бывает и больше, но для 4-ядерной тестовой среды это признак того, что кукушка улетела.

 

В зависимости от числа физических чтений, считается IOPS только по чтению.

 

declare @mfDESC__ROWS_num_of_reads INT

SELECT @mfDESC__ROWS_num_of_reads=6000

 

SELECT @mfDESC__ROWS_num_of_reads/60. AS IOPS,

1120.59

+4.75542*@mfDESC__ROWS_num_of_reads

+105.96*SQRT(abs(117.508)+@mfDESC__ROWS_num_of_reads) AS ms

 

В зависимости от числа считанных байт:

 

declare @mfDESC__ROWS_num_of_bytes_read float

SELECT @mfDESC__ROWS_num_of_bytes_read=20e6

 

select @mfDESC__ROWS_num_of_bytes_read/1e6 AS MbPerMin,

6809.88

+-0.000276395*@mfDESC__ROWS_num_of_bytes_read

+8.46543*SQRT(abs(31004)+@mfDESC__ROWS_num_of_bytes_read) AS ms

 

Примечание- файлы данных на размеченном под 16К диске.

То есть, с помощью этих формул можно вполне предметно предсказать производительность сервера (задержки на чтение из файлов данных) при некотором количестве обращений к диску или некотором объеме считанных байт.

 

 

 

Вот так выглядит полная формула (см ниже). Видно какое именно влияние оказывает какой конкретно фактор.

 

select mfDESC__ROWS_io_stall_read_ms,

2.41992

–+-0.931846*isnull(mf__io_stall_read_ms,0)

+0.603248*isnull(mf__io_stall_write_ms,0)

+-0.00070104*isnull(mf__num_of_bytes_read,0)

+-0.00112982*isnull(mf__num_of_bytes_written,0)

+86.29*isnull(mf__num_of_reads,0)

+-2.79657*isnull(mf__num_of_writes,0)

+-2.14782*isnull(mfDESC__LOG__io_stall_read_ms,0)

+1.79957*isnull(mfDESC__LOG__io_stall_write_ms,0)

+0.000152735*isnull(mfDESC__LOG__num_of_bytes_read,0)

+-0.000308365*isnull(mfDESC__LOG__num_of_bytes_written,0)

+-5.39451*isnull(mfDESC__LOG__num_of_reads,0)

+1.04204*isnull(mfDESC__LOG__num_of_writes,0)

–+-0.0776722*isnull(mfDESC__ROWS_io_stall_read_ms,0)

+-0.689693*isnull(mfDESC__ROWS_io_stall_write_ms,0)

+0.000430669*isnull(mfDESC__ROWS_num_of_bytes_read,0)

+-0.0019424*isnull(mfDESC__ROWS_num_of_bytes_written,0)

+83.043*isnull(mfDESC__ROWS_num_of_reads,0)

+-2.14832*isnull(mfDESC__ROWS_num_of_writes,0)

+0.015625*isnull(Page_life_expectancy,0)

+2.85669*isnull(Page_reads_sec,0)

+0.316406*isnull(Page_writes_sec,0)

+43.0981*isnull(_wait_PAGEIOLATCH,0)

+1.90405*isnull(_wait_PAGELATCH,0)

+-8.78632*isnull(_wait_LATCH,0)

+-7.95685*isnull(_wait_LCK_M,0)

+0.3468*isnull(_wait_IO_COMPLETION,0)

+0.0335543*isnull(_wait_ASYNC_IO_COMPLETION,0)

+-2.03154*isnull(_wait_BACKUPIO,0)

+0.41675*isnull(_wait_SOS_SCHEDULER_YIELD,0)

+-0.000737278*isnull(_wait_CXPACKET,0)

+17.0514*isnull(_wait_LOGBUFFER,0)

+-4.98295e-005*isnull(Backup_Restore_Throughput,0)

+0.000107393*isnull(DBCC_Logical_Scan,0)

+-0.0150967*isnull(Page_lookups,0)

+1.3324*isnull(Page_reads,0)

+5.51172*isnull(Page_Splits,0)

+0.744141*isnull(Page_writes,0)

+2.16699*isnull(Pages_Allocated,0)

 

–+0.616415*SQRT(isnull(mf__io_stall_read_ms,0))

+3.84741*SQRT(isnull(mf__io_stall_write_ms,0))

+0.282959*SQRT(isnull(mf__num_of_bytes_read,0))

+-1.28906*SQRT(isnull(mf__num_of_bytes_written,0))

+45.125*SQRT(isnull(mf__num_of_reads,0))

+-2.18848*SQRT(isnull(mf__num_of_writes,0))

+-2.6629*SQRT(isnull(mfDESC__LOG__io_stall_read_ms,0))

+3.19225*SQRT(isnull(mfDESC__LOG__io_stall_write_ms,0))

+-2.2733*SQRT(isnull(mfDESC__LOG__num_of_bytes_read,0))

+3.52891*SQRT(isnull(mfDESC__LOG__num_of_bytes_written,0))

+-1.58588*SQRT(isnull(mfDESC__LOG__num_of_reads,0))

+3.74249*SQRT(isnull(mfDESC__LOG__num_of_writes,0))

–+-1.15257*SQRT(isnull(mfDESC__ROWS_io_stall_read_ms,0))

+-0.223877*SQRT(isnull(mfDESC__ROWS_io_stall_write_ms,0))

+1.35327*SQRT(isnull(mfDESC__ROWS_num_of_bytes_read,0))

+3.57594*SQRT(isnull(mfDESC__ROWS_num_of_bytes_written,0))

+44.4766*SQRT(isnull(mfDESC__ROWS_num_of_reads,0))

+-2.35156*SQRT(isnull(mfDESC__ROWS_num_of_writes,0))

+-2.73535*SQRT(isnull(Page_life_expectancy,0))

+-9.28906*SQRT(isnull(Page_reads_sec,0))

+0.195801*SQRT(isnull(Page_writes_sec,0))

+0.520264*SQRT(isnull(_wait_PAGEIOLATCH,0))

+0.09375*SQRT(isnull(_wait_PAGELATCH,0))

+-12.9844*SQRT(isnull(_wait_LATCH,0))

+6.53271*SQRT(isnull(_wait_LCK_M,0))

+-3.47168*SQRT(isnull(_wait_IO_COMPLETION,0))

+-0.89661*SQRT(isnull(_wait_ASYNC_IO_COMPLETION,0))

+-1.54214*SQRT(isnull(_wait_BACKUPIO,0))

+3.51346*SQRT(isnull(_wait_SOS_SCHEDULER_YIELD,0))

+-1.04117*SQRT(isnull(_wait_CXPACKET,0))

+17.1316*SQRT(isnull(_wait_LOGBUFFER,0))

+-0.543945*SQRT(isnull(Backup_Restore_Throughput,0))

+-3.9375*SQRT(isnull(DBCC_Logical_Scan,0))

+3.98828*SQRT(isnull(Page_lookups,0))

+-9.28906*SQRT(isnull(Page_reads,0))

+-5.05859*SQRT(isnull(Page_Splits,0))

+0.161682*SQRT(isnull(Page_writes,0))

+-3.83008*SQRT(isnull(Pages_Allocated,0))

FROM [dbo].[***]

 

Использовалась методика описанная здесь: Аналитическая работа- использование методологии ОТС (общая теория систем) для анализа бизнес процессов и прогнозирования их состояния.

Удачная и эффективная методика получилась. Можно считать все что угодно, любой черный ящик. В данном случае- статистику MS SQL Server

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *