Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 SQLIO и результаты  [new]
se111
Member

Откуда:
Сообщений: 34
Добрый день, проанализировал диск C с помощью SQLIO,
как описано тут
Мне не с чем сравнить, на сервере raid Smart Array P410i
Array Accelerator (Cache) Ratio стоит в 100%read/0%Write
по счетчику Disk Queue для диска D видно, что именно read очередь вырастает до 70-100,
начинаются висяки(Может дело и в неправильных запросах, но как отследить пока не знаю) . База 1с, 170гб, Регламент каждую ночь Reorganize и обновление статистики, бэкап. По воскресениям еще и rebuild.
Cache Hit Ratio ~ 67-85%
Buffer Cache Hit ratio ~ 98-99%
База data диск D Raid 10 SAS 4x 300Gb
Логи диск C Raid 10 SAS 4x 300Gb

Проверил диск C на скорость но сравнить не с чем, и не знаю нормально ли это.
Вот еще вопрос, Диск C вообще не нагружен, т.е. в связи с тем что база в Simple, нагрузки нет, и затыки именно на чтении - может Объединить весь Raid и сделать 8x300 в один десятый? вместо двух как сейчас?


legend:
---------------------
Threads = [T]
ReadWrite = [RW]
Duration - везде 120
IOPattern - [IOPat]
FileSizeMB = [FSize]
IOsSec = [Is]
MBsSec = [Ms]
LatencyMs_Min= [1]
LatencyMs_Avg= [2]
LatencyMs_Max= [3]
---------------------

[T] [RW] [IOPat] [FSize] [Is] [Ms] [1] [2] [3]
2 W random 14148 550 34 0 6 224
2 W random 14148 564 35 0 13 392
2 W random 14148 565 35 0 27 621
2 W random 14148 576 36 0 54 760
2 W random 14148 593 37 0 107 711
2 W random 14148 594 37 0 214 846
2 W random 14148 597 37 2 427 1256
4 W random 14148 553 35 0 6 262
4 W random 14148 555 35 0 13 267
4 W random 14148 567 35 0 27 570
4 W random 14148 573 36 0 55 759
4 W random 14148 588 37 0 108 740
4 W random 14148 588 37 0 217 1072
4 W random 14148 593 37 2 430 1173
4 W random 14148 592 37 19 861 1728
8 W random 14148 550 34 0 14 431
8 W random 14148 560 35 0 28 603
8 W random 14148 574 36 0 55 1005
8 W random 14148 587 37 0 108 876
8 W random 14148 598 37 0 213 825
8 W random 14148 598 37 1 426 1231
8 W random 14148 592 37 17 861 1901
8 W random 14148 600 37 24 1692 2571
16 W random 14148 565 35 0 27 602
16 W random 14148 573 36 0 55 860
16 W random 14148 589 37 0 107 774
16 W random 14148 594 37 0 214 781
16 W random 14148 596 37 1 427 1257
16 W random 14148 582 36 17 876 1947
16 W random 14148 590 37 17 1723 2628
16 W random 14148 588 37 35 3427 4389
32 W random 14148 573 36 0 55 614
32 W random 14148 586 37 0 108 705
32 W random 14148 594 37 0 214 928
32 W random 14148 591 37 1 431 1183
32 W random 14148 584 37 18 872 1751
32 W random 14148 587 37 25 1731 2716
32 W random 14148 595 37 49 3386 4288
32 W random 14148 591 37 97 6729 8102
64 W random 14148 583 36 0 109 757
64 W random 14148 582 36 0 219 985
64 W random 14148 588 37 1 433 1224
64 W random 14148 597 37 18 854 2023
64 W random 14148 602 38 22 1689 2580
64 W random 14148 593 37 51 3410 4435
64 W random 14148 601 38 97 6621 7714
64 W random 14148 598 37 179 13014 14820
2 R random 14148 388 24 0 4 64
2 R random 14148 552 34 0 6 39
2 R random 14148 736 46 0 10 81
2 R random 14148 962 60 0 16 287
2 R random 14148 1159 72 0 27 399
2 R random 14148 1274 80 0 49 625
2 R random 14148 1315 82 1 96 1010
2 R random 14148 1327 83 6 192 842
4 R random 14148 534 33 0 6 105
4 R random 14148 721 45 0 10 235
4 R random 14148 948 59 0 16 312
4 R random 14148 1153 72 0 27 333
4 R random 14148 1270 79 0 49 575
4 R random 14148 1320 83 0 96 703
4 R random 14148 1322 83 4 192 1084
4 R random 14148 1327 83 10 384 950
8 R random 14148 722 45 0 10 78
8 R random 14148 944 59 0 16 447
8 R random 14148 1156 72 0 27 341
8 R random 14148 1264 79 0 50 653
8 R random 14148 1320 83 1 96 1118
8 R random 14148 1314 82 6 194 815
8 R random 14148 1302 81 10 391 1031
8 R random 14148 1311 82 30 777 1422
16 R random 14148 841 53 0 18 259
16 R random 14148 1058 66 0 29 431
16 R random 14148 1231 77 0 51 666
16 R random 14148 1283 80 0 99 599
16 R random 14148 1297 81 7 196 987
16 R random 14148 1312 82 7 388 1213
16 R random 14148 1310 82 12 778 1328
16 R random 14148 1336 84 32 1521 2173
32 R random 14148 1085 68 0 28 351
32 R random 14148 1242 78 0 51 618
32 R random 14148 1312 82 1 97 1036
32 R random 14148 1332 83 5 191 974
32 R random 14148 1333 83 8 382 922
32 R random 14148 1333 83 8 765 1535
32 R random 14148 1342 84 19 1515 2111
32 R random 14148 1349 84 45 2995 3647
64 R random 14148 1247 78 1 50 618
64 R random 14148 1311 82 0 97 697
64 R random 14148 1320 82 5 193 839
64 R random 14148 1326 83 6 385 1057
64 R random 14148 1328 83 8 768 1384
64 R random 14148 1341 84 18 1515 2166
64 R random 14148 1341 84 30 3014 3953
64 R random 14148 1351 84 63 5920 6678
2 W sequential 14148 1522 95 0 0 569
2 W sequential 14148 1977 124 0 1 712
2 W sequential 14148 2523 158 0 2 301
2 W sequential 14148 2786 174 0 5 155
2 W sequential 14148 3148 197 0 9 374
2 W sequential 14148 3479 217 0 17 419
2 W sequential 14148 3777 236 0 33 709
2 W sequential 14148 3859 241 1 65 718
4 W sequential 14148 1674 105 0 1 163
4 W sequential 14148 1991 124 0 3 180
4 W sequential 14148 2775 173 0 5 140
4 W sequential 14148 2707 169 0 11 226
4 W sequential 14148 3531 221 0 17 192
4 W sequential 14148 3652 228 0 34 500
4 W sequential 14148 3775 236 1 67 678
4 W sequential 14148 3961 248 17 128 256
8 W sequential 14148 1796 112 0 3 143
8 W sequential 14148 3056 191 0 4 151
8 W sequential 14148 3298 206 0 9 155
8 W sequential 14148 3632 227 0 17 596
8 W sequential 14148 3677 230 0 34 255
8 W sequential 14148 3671 229 1 69 185
8 W sequential 14148 3885 243 16 131 385
8 W sequential 14148 3995 250 38 255 692
16 W sequential 14148 3054 191 0 4 458
16 W sequential 14148 3227 202 0 9 162
16 W sequential 14148 3660 229 0 16 169
16 W sequential 14148 3636 227 0 34 760
16 W sequential 14148 3813 238 1 66 218
16 W sequential 14148 3981 249 15 128 953
16 W sequential 14148 4097 256 25 249 506
16 W sequential 14148 4086 255 58 499 1184
32 W sequential 14148 3299 206 0 9 219
32 W sequential 14148 3541 221 0 17 230
32 W sequential 14148 3705 232 0 34 723
32 W sequential 14148 3749 234 1 67 715
32 W sequential 14148 3967 248 18 128 336
32 W sequential 14148 4087 255 26 249 685
32 W sequential 14148 4158 260 44 490 1315
32 W sequential 14148 4181 261 86 974 2400
64 W sequential 14148 3600 225 0 17 466
64 W sequential 14148 3652 228 0 34 425
64 W sequential 14148 3885 243 1 65 198
64 W sequential 14148 3944 246 15 129 665
64 W sequential 14148 3991 249 20 255 673
64 W sequential 14148 4060 254 61 502 1289
64 W sequential 14148 4104 257 138 992 2337
64 W sequential 14148 4174 261 219 1944 4334
2 R sequential 14148 1087 68 0 1 700
2 R sequential 14148 1168 73 0 2 254
2 R sequential 14148 1602 100 0 4 218
2 R sequential 14148 2575 161 0 5 331
2 R sequential 14148 3277 205 0 9 237
2 R sequential 14148 3231 202 0 19 161
2 R sequential 14148 3732 233 0 33 252
2 R sequential 14148 4157 260 1 61 144
4 R sequential 14148 1071 67 0 3 180
4 R sequential 14148 2108 132 0 3 266
4 R sequential 14148 3014 188 0 4 314
4 R sequential 14148 3708 232 0 8 669
4 R sequential 14148 3487 218 0 17 276
4 R sequential 14148 3785 237 0 33 146
4 R sequential 14148 4171 261 1 60 204
4 R sequential 14148 4367 273 17 116 197
8 R sequential 14148 2317 145 0 2 403
8 R sequential 14148 3137 196 0 4 314
8 R sequential 14148 3556 222 0 8 370
8 R sequential 14148 3435 215 0 18 183
8 R sequential 14148 3815 238 0 33 181
8 R sequential 14148 4188 262 1 60 198
8 R sequential 14148 4375 273 17 116 192
8 R sequential 14148 4489 281 31 227 347
16 R sequential 14148 3168 198 0 4 584
16 R sequential 14148 3438 215 0 8 280
16 R sequential 14148 3433 215 0 18 255
16 R sequential 14148 3838 240 0 32 217
16 R sequential 14148 4304 269 0 58 159
16 R sequential 14148 4346 272 10 117 223
16 R sequential 14148 4470 279 25 228 398
16 R sequential 14148 4557 285 44 447 549
32 R sequential 14148 3431 214 0 8 283
32 R sequential 14148 3357 210 0 18 166
32 R sequential 14148 3754 235 0 33 174
32 R sequential 14148 4147 259 1 61 196
32 R sequential 14148 4348 272 8 117 263
32 R sequential 14148 4473 280 10 228 344
32 R sequential 14148 4547 284 19 448 593
32 R sequential 14148 4579 286 41 889 1161
64 R sequential 14148 3326 208 0 18 172
64 R sequential 14148 3758 235 0 33 166
64 R sequential 14148 4167 260 0 60 191
64 R sequential 14148 4353 272 5 117 195
64 R sequential 14148 4471 279 6 228 351
64 R sequential 14148 4523 283 13 451 574
64 R sequential 14148 4561 285 21 893 1169
64 R sequential 14148 4583 286 70 1772 2436
3 фев 12, 09:41    [12023933]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
http://msmvps.com/blogs/gladchenko/archive/2009/06/09/1694801.aspx
3 фев 12, 12:31    [12025375]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
se111
Member

Откуда:
Сообщений: 34
Спасибо. но там почти тоже самое, что и по ссылке выше.
3 фев 12, 14:32    [12026730]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
se111
...Диск C вообще не нагружен, т.е. в связи с тем что база в Simple, нагрузки нет...

Нагрузку на базу определяет не модель восстановления, а характер нагрузки.

se111
...затыки именно на чтении...



Вначале: Убедитесь, что запросы попадают в индексы и файлы данных не на том же диске, где файл журнала транзакций.
Потом: Проанализируйте блокировки

se111
...может Объединить весь Raid и сделать 8x300 в один десятый? вместо двух как сейчас?...


Это точно будет хуже, чем два зеркала, как сейчас.
3 фев 12, 14:59    [12027136]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
Александр Гладченко
se111
...может Объединить весь Raid и сделать 8x300 в один десятый? вместо двух как сейчас?...


Это точно будет хуже, чем два зеркала, как сейчас.
Почему же, может у se111 вообще обновлений практически нету?

Нужно просто посмотреть статистику по дискам, файлам, и решить.

Если С действительно совсем ненагружен, то можно и слить 2 рейда в 1

Или сделать 2 файла в праймари-файлгруппе, по файлу на рейд. Может это будет даже и быстрее. Только нужно будет данные распределить, это как бы более хлопотно.
3 фев 12, 15:44    [12027840]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
alexeyvg,

Алексей, я не согласен. Вопервых, дисковая подсистема потеряет в суммарной производительности от укрупнения до RAID10 (рост накладных расходов и связности, я как то показывал пример с графиками). Вовторых, плохо мешать разнородную нагрузку на одной группе шпинделей, особенно, если шпинделей не много.
Самое правильное, добавить шпинделей (если очереди не из-за отсутствия индексов).

Сообщение было отредактировано: 3 фев 12, 17:09
3 фев 12, 17:07    [12028802]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
Александр Гладченко
Алексей, я не согласен. Вопервых, дисковая подсистема потеряет в суммарной производительности от укрупнения до RAID10 (рост накладных расходов и связности, я как то показывал пример с графиками).
Хм, в смысле, увеличение RAID10 с 4-х дисков до 8-ми уменьшит производительность?

А вообще для скорости лучьше сделать 4 зеркала, и разместить на нём равномерно разбитую по файлам файлгруппу.
3 фев 12, 21:21    [12030323]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
alexeyvg,

Я имел ввиду потери относительно варианта с RAID1.
6 фев 12, 11:12    [12038866]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
se111
Member

Откуда:
Сообщений: 34
alexeyvg
Хм, в смысле, увеличение RAID10 с 4-х дисков до 8-ми уменьшит производительность?

А вообще для скорости лучьше сделать 4 зеркала, и разместить на нём равномерно разбитую по файлам файлгруппу.


Я читал про то, что сам sql лучше управляет распределением\распараллеливанием запросов, относительно простых raid контроллеров. тут стоит smart array P410i, который считается относительно неплохим. Как вариант рассмотрю, спасибо.

alexeyvg
Почему же, может у se111 вообще обновлений практически нету?

Нужно просто посмотреть статистику по дискам, файлам, и решить.

Как это посмотреть?

Александр Гладченко
Вначале: Убедитесь, что запросы попадают в индексы и файлы данных не на том же диске, где файл журнала транзакций.
Потом: Проанализируйте блокировки

Журнал транзакций сейчас на отдельном диске, там нет файлов данных, кроме конечно стандартных tempdb, model, master, msdb.

Александр Гладченко
Самое правильное, добавить шпинделей (если очереди не из-за отсутствия индексов).

к сожалению на сервере нет больше свободных портов для винтов. давно бы уже сделал.
Как исключить очередь из за отсутствия индексов? т.е. как посмотреть, что это не из за отсутствия индексов или наоборот?
Разве Rebuild Indexes, который создается через Maintenance Wizard, и делается раз в неделю не исключает эту ситуацию?
6 фев 12, 15:11    [12041033]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
se111
к сожалению на сервере нет больше свободных портов для винтов. давно бы уже сделал.
Как исключить очередь из за отсутствия индексов? т.е. как посмотреть, что это не из за отсутствия индексов или наоборот?

Купите ещё один адаптер или подключите внешнюю СХД.

se111
Разве Rebuild Indexes, который создается через Maintenance Wizard, и делается раз в неделю не исключает эту ситуацию?

Нет, пересоздание индексов не строит новые индексы. Недостающие индексы может подсказать траасировка запросов с воспроизведением на тестовом сервере или более простой путь: http://msmvps.com/blogs/gladchenko/archive/2007/11/14/1311293.aspx
6 фев 12, 15:18    [12041115]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
se111
alexeyvg
Хм, в смысле, увеличение RAID10 с 4-х дисков до 8-ми уменьшит производительность?

А вообще для скорости лучьше сделать 4 зеркала, и разместить на нём равномерно разбитую по файлам файлгруппу.


Я читал про то, что сам sql лучше управляет распределением\распараллеливанием запросов, относительно простых raid контроллеров. тут стоит smart array P410i, который считается относительно неплохим. Как вариант рассмотрю, спасибо.
Это лучьше даже для топовых СХД, а не только для "топового" контроллера smart array P410i :-)

Тут проблема-то не только в работе дисковой системы, но и в софте, в интерфейсе компьютер-диски. Винды так быстрее работают.
se111
alexeyvg
Почему же, может у se111 вообще обновлений практически нету?

Пониблюдайте, статистика - это ключевой момент, без этого нельзя принимать решений. Может, у вас не в дисках узкое место.

Нужно просто посмотреть статистику по дискам, файлам, и решить.

Как это посмотреть?
Ну, я не знаю, как у вас на Windows NT и SQL 2000 :-) , а на Win 2008 можно просто вызвать таск-менеджер и кликнуть на вкладке Performance Resource Monitor.

Там уже посмотреть на вкладке дисков - будет и очередь, и задержки, и трафик пол дискам и файлам, по чтению и записи...
6 фев 12, 18:38    [12043071]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
Вот несколько ссылок по идентификации проблем дисковой подсистемы и статистике ожиданий ввода-вывода:
http://msmvps.com/blogs/gladchenko/archive/2011/09/21/1799948.aspx
http://msmvps.com/blogs/gladchenko/archive/2010/12/16/1784447.aspx
http://msmvps.com/blogs/gladchenko/archive/2009/09/28/1727878.aspx
http://msmvps.com/blogs/gladchenko/archive/2008/06/16/1635705.aspx

Сообщение было отредактировано: 7 фев 12, 10:46
7 фев 12, 10:44    [12045241]     Ответить | Цитировать Сообщить модератору
 Re: SQLIO и результаты  [new]
se111
Member

Откуда:
Сообщений: 34
Спасибо, буду разбираться. по результатам отпишусь.
7 фев 12, 14:47    [12047298]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить