| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
Злравствуйте, имеется Microsoft SQL Server 2005 - 9.00.5000.00 (X64) Dec 10 2010 10:38:40 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 (Build 7600: ), 32ГБ оперативки, 4 cpu * 6 cores 1.87 GHz, OLTP. Файл данных базы 90ГБ, индексы 35 Гб, tempdb около 90 ГБ Есть корзина SAS 24 диска 146 ГБ 15К, подскажите, пожалуйста какой вариант разбития выбрать. Пока подумываю разбить на 4 raid 10(по 6 дисков)- для файлов данных, индексов, логов и tempdb. Буду рад любым советам и предложениям, заранее спасибо! |
| 29 авг 12, 09:54 [13079952] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Если вы её не знаете, то нужно или её замерять, или правильно прогнозировать, или не делать такое сложное разбиение, ограничиться простым "рейд для данных + рейд для логов". |
||
| 29 авг 12, 10:21 [13080140] Ответить | Цитировать Сообщить модератору | |||
| Re: Выбор raid для ms sql
|
|
|
gang Member Откуда: Сообщений: 1394 |
karu, Для логов хватит 2 дисков в зеркале. Т.к. операции с логом последовательные, то параллелиться на n шпинделей они все равно не будут. Лучше больше по количеству выделить под данные и индексы. И какое-то странное у вас соотношение по размерам. tempdb=prod DB? Оно там точно нужно такого размера? И индексы толстоваты на первый взгляд. Филлфакор/фрагментация? |
| 29 авг 12, 10:21 [13080145] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|||
|
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37155 |
|
||
| 29 авг 12, 10:33 [13080235] Ответить | Цитировать Сообщить модератору | |||
| Re: Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
gang, tempdb разрослась очень, сделал shrink до 50ГБ, у индексов fii factor 75%, файловые группы, в которых находятся индексы не фрагментированы. |
| 29 авг 12, 10:42 [13080298] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|||||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Если конечно рост tempdb не разовое явление из за какой то конкретной разовой операции, которой больше никогда не будет.
|
||||||
| 29 авг 12, 10:52 [13080392] Ответить | Цитировать Сообщить модератору | |||||||
| Re: Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
alexeyvg, сейчас ВСЕ лежит на одном диске(raid 5 из 5 дисков), не подскажите как помониторить нагрузку на отдельные файлы БД? |
| 29 авг 12, 10:58 [13080440] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
Windows server 2008 r2, в resource monitor можно посмотреть чтение\запись отдельных файлов online, но не знаю как собрать статистику за длительный период( |
| 29 авг 12, 11:21 [13080734] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
А вообще есть смециальные системные вьюхи в MSSQL, правда насчёт версии 2005 не могу точно сказать. В 2008-м это выглядит так: select * from sys.dm_io_virtual_file_stats (null, null) |
||
| 29 авг 12, 11:56 [13081095] Ответить | Цитировать Сообщить модератору | |||
| Re: Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
alexeyvg, спасибо, отлично, нашел топовые суммарные объемы чтения\записи файлов (это за 4 месяца). read GB 10334 D:\data\testdb.mdf 1915 D:\data\tempdb.mdf 1452 D:\data\testdb_indexes_1.mdf 1380 D:\data\testdb_indexes_2.mdf 418 D:\data\UDE_data.mdf 284 D:\data\UDE_indexes_1.mdf write GB 2581 D:\data\tempdb.mdf 2103 D:\data\testdb_log.ldf 1038 D:\data\testdb.mdf 353 D:\data\testdb_indexes_2.mdf 276 D:\data\testdb_indexes_1.mdf 264 d:\data\templog.ldf 23 D:\data\UDE_log.ldf testdb- основная база, ude- поменьше. Может побить на raid10 (12,4,4,4 дисков) соответственно для файлов данных, логов, tempdb и индексов? Или(10,6,4,4). Господа, как считаете?) |
| 29 авг 12, 14:35 [13082563] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|
|
karu Member Откуда: Сообщений: 34 |
Или (8,6,6,4) диска. Вариантов масса, конечно. |
| 29 авг 12, 14:54 [13082785] Ответить | Цитировать Сообщить модератору | |
| Re: Выбор raid для ms sql
|
|||||||||
|
gang Member Откуда: Сообщений: 1394 |
Согласен. Неправильно выразился. Единичные операции параллелиться будут и будут в всязи с этим проходить быстрее. Насколько быстрее, это сильно зависит от размера записи лога. Если он не велик, то и выигрыш будет незаметен. Не очень представляю себе например как будет распараллелен контроллером массива запрос на запись одной 8-килобайтной страницы лога при стандарном размере страйпа массива в 256К. Если поделитесь инфой\ссылкой буду очень благодарен. Кроме того имел в виду что поскольку запись в лог последовательная, то эти операции будут идти одна за другой без возможности одновременного выполнения на разных шпинделях. Для файлов данных такое возможно, соответственно и выигрыш от использования бОльшего числа шпинделей можно получить более заметный. Использование же кеша с размером массива никак не связано.
Мое ИМХО, но потребность в индексах превышающих объем данных это не вполне нормально. Скорее походит на ошибки проектирования структуры данных. У автора кстати получается ~1:3 и еще с филфактором 75 что, опять же на мой личный взгляд, вполне нормально. |
||||||||
| 29 авг 12, 15:12 [13082965] Ответить | Цитировать Сообщить модератору | |||||||||
| Re: Выбор raid для ms sql
|
|||
|
gang Member Откуда: Сообщений: 1394 |
Я бы остановился на 12,4,4,4 Все-таки объем чтений у вас в 5 раз больше записи. |
||
| 29 авг 12, 15:14 [13082986] Ответить | Цитировать Сообщить модератору | |||
| Re: Выбор raid для ms sql
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
На файлы с индексами нагрузка раз в 5 меньше, чем на файлы данных (на чтение и запись). На лог нагрузка большая (на запись). На темпдб нагрузка большая (на запись, на чтение не особо). Исходя из этого, выделять отдельные рейды на индексы имхо неправильно. На логи обязательно, на темпдб в принципе желательно. Вообще по моему идеальный вариант был бы в распределении данных testdb и tempdb равномерно по нескольким файлам, и распределение этих файлов на несколько рейдов, по идее хотя бы по числу сокетов. Т.е. сделать: RAID10 x 8 - файлы логов testdb и tempdb RAID10 x 4 - файлы данных testdb и tempdb RAID10 x 4 - файлы данных testdb и tempdb RAID10 x 4 - файлы данных testdb и tempdb RAID10 x 4 - файлы данных testdb и tempdb Но этим будет конечно немного сложнее управлять (типа, можно запутаться в количестве файлов, или какой то чайник может не суметь бакапы восстановить). Да и начальная инициализация будет сложновата для неподготовленного человека, поскольку команды "распределить существующие данные по файлам" в сиквеле нет (тут речь только о testdb, для tempdb это сделать легко). Если хочется максимальной простоты, то можно по простому: RAID10 x 8 - файлы логов testdb и tempdb RAID10 x 16 - файлы данных testdb и tempdb Контроллеры сейчас хорошие, если совсем разные типы нагрузки не мешать, то будет нормально. |
||
| 29 авг 12, 15:17 [13083010] Ответить | Цитировать Сообщить модератору | |||
| Re: Выбор raid для ms sql
|
|||||
|
gang Member Откуда: Сообщений: 1394 |
Хотя нет. Лучше все-таки по 2 у лога и данных урвать и отдать индексам: 10,2,4,8 Данные, Лог, Tempdb, Index |
||||
| 29 авг 12, 15:17 [13083013] Ответить | Цитировать Сообщить модератору | |||||
| Re: Выбор raid для ms sql
|
|||||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31783 |
Тогда на контроллер будет идти поток записи последовательных секторов, и он будет этот поток распаралеливать на несколько дисков (т.е. в потоке ведь не будет ожидания записи 8 кб блока, там будет сразу много таких блоков в очереди на запись, вот он их и будет раскидывать на разные диски) Конечно, если один сиквельный коннект будет в цикле делать инсёрты, и при этом кеша записи в рейд-контроллере нету, то большой рейд будет не быстрее (а може и медленнее) пары дисков в зеркале.
Хотя согласен, нужно такие случаи специально исследовать - может быть ошибки проектирования структуры данных, а может просто элементарный бардак, когда разные программисты создают почти одинаковые индексы, хотя можно было бы обойтись меньшим количеством... |
||||||
| 29 авг 12, 15:31 [13083151] Ответить | Цитировать Сообщить модератору | |||||||
| Все форумы / Microsoft SQL Server | |
|
x