Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Выбор raid для ms sql  [new]
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  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32175
karu
Пока подумываю разбить на 4 raid 10(по 6 дисков)- для файлов данных, индексов, логов и tempdb.
Зависит от нагрузки на файлы данных, индексов, логов и tempdb

Если вы её не знаете, то нужно или её замерять, или правильно прогнозировать, или не делать такое сложное разбиение, ограничиться простым "рейд для данных + рейд для логов".
29 авг 12, 10:21    [13080140]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
gang
Member

Откуда:
Сообщений: 1394
karu,

Для логов хватит 2 дисков в зеркале. Т.к. операции с логом последовательные, то параллелиться на n шпинделей они все равно не будут. Лучше больше по количеству выделить под данные и индексы.

И какое-то странное у вас соотношение по размерам. tempdb=prod DB? Оно там точно нужно такого размера?
И индексы толстоваты на первый взгляд. Филлфакор/фрагментация?
29 авг 12, 10:21    [13080145]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
gang
karu,

Для логов хватит 2 дисков в зеркале. Т.к. операции с логом последовательные, то параллелиться на n шпинделей они все равно не будут.
Чо это они не будут параллелиться в одном рейде?
29 авг 12, 10:33    [13080235]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
karu
Member

Откуда:
Сообщений: 34
gang, tempdb разрослась очень, сделал shrink до 50ГБ, у индексов fii factor 75%, файловые группы, в которых находятся индексы не фрагментированы.
29 авг 12, 10:42    [13080298]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32175
gang
Для логов хватит 2 дисков в зеркале. Т.к. операции с логом последовательные, то параллелиться на n шпинделей они все равно не будут. Лучше больше по количеству выделить под данные и индексы.
Всё нормально параллелится. В отличие от файлов данных, распаллалелить запись в лог можно только созданием рейда на много дисков. Если там ещё и кеш на запись с батарейкой, то вообще будет всё прекрасно работать.
karu
tempdb разрослась очень, сделал shrink до 50ГБ,
Зачем делать шринк? Разрослась - значит, такой размер нужен вашему приложению, и значит tempdb опять вырастет. То есть шринком вы добиваетесь только физической фрагментации файлов tempdb.

Если конечно рост tempdb не разовое явление из за какой то конкретной разовой операции, которой больше никогда не будет.
gang
И индексы толстоваты на первый взгляд
Это же зависит от потребности в индексах, они могут быть и больше файлов данных, это совершенно нормально, и ровно ни о чём не говорит.
29 авг 12, 10:52    [13080392]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
karu
Member

Откуда:
Сообщений: 34
alexeyvg, сейчас ВСЕ лежит на одном диске(raid 5 из 5 дисков), не подскажите как помониторить нагрузку на отдельные файлы БД?
29 авг 12, 10:58    [13080440]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
karu
Member

Откуда:
Сообщений: 34
Windows server 2008 r2, в resource monitor можно посмотреть чтение\запись отдельных файлов online, но не знаю как собрать статистику за длительный период(
29 авг 12, 11:21    [13080734]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32175
karu
alexeyvg, сейчас ВСЕ лежит на одном диске(raid 5 из 5 дисков), не подскажите как помониторить нагрузку на отдельные файлы БД?
Да, в Windows server 2008 r2 в resource monitor можно.

А вообще есть смециальные системные вьюхи в MSSQL, правда насчёт версии 2005 не могу точно сказать.

В 2008-м это выглядит так:
select * from sys.dm_io_virtual_file_stats (null, null)
29 авг 12, 11:56    [13081095]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
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  [new]
karu
Member

Откуда:
Сообщений: 34
Или (8,6,6,4) диска. Вариантов масса, конечно.
29 авг 12, 14:54    [13082785]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
gang
Member

Откуда:
Сообщений: 1394
alexeyvg
gang
Для логов хватит 2 дисков в зеркале. Т.к. операции с логом последовательные, то параллелиться на n шпинделей они все равно не будут. Лучше больше по количеству выделить под данные и индексы.
Всё нормально параллелится. В отличие от файлов данных, распаллалелить запись в лог можно только созданием рейда на много дисков. Если там ещё и кеш на запись с батарейкой, то вообще будет всё прекрасно работать.


Согласен. Неправильно выразился. Единичные операции параллелиться будут и будут в всязи с этим проходить быстрее. Насколько быстрее, это сильно зависит от размера записи лога. Если он не велик, то и выигрыш будет незаметен. Не очень представляю себе например как будет распараллелен контроллером массива запрос на запись одной 8-килобайтной страницы лога при стандарном размере страйпа массива в 256К. Если поделитесь инфой\ссылкой буду очень благодарен. Кроме того имел в виду что поскольку запись в лог последовательная, то эти операции будут идти одна за другой без возможности одновременного выполнения на разных шпинделях. Для файлов данных такое возможно, соответственно и выигрыш от использования бОльшего числа шпинделей можно получить более заметный. Использование же кеша с размером массива никак не связано.

alexeyvg
gang
И индексы толстоваты на первый взгляд
Это же зависит от потребности в индексах, они могут быть и больше файлов данных, это совершенно нормально, и ровно ни о чём не говорит.

Мое ИМХО, но потребность в индексах превышающих объем данных это не вполне нормально. Скорее походит на ошибки проектирования структуры данных. У автора кстати получается ~1:3 и еще с филфактором 75 что, опять же на мой личный взгляд, вполне нормально.
29 авг 12, 15:12    [13082965]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
gang
Member

Откуда:
Сообщений: 1394
karu
Или (8,6,6,4) диска. Вариантов масса, конечно.

Я бы остановился на 12,4,4,4
Все-таки объем чтений у вас в 5 раз больше записи.
29 авг 12, 15:14    [13082986]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32175
karu
alexeyvg, спасибо, отлично, нашел топовые суммарные объемы чтения\записи файлов (это за 4 месяца).

На файлы с индексами нагрузка раз в 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  [new]
gang
Member

Откуда:
Сообщений: 1394
gang
karu
Или (8,6,6,4) диска. Вариантов масса, конечно.

Я бы остановился на 12,4,4,4
Все-таки объем чтений у вас в 5 раз больше записи.

Хотя нет. Лучше все-таки по 2 у лога и данных урвать и отдать индексам:
10,2,4,8
Данные, Лог, Tempdb, Index
29 авг 12, 15:17    [13083013]     Ответить | Цитировать Сообщить модератору
 Re: Выбор raid для ms sql  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32175
gang
Насколько быстрее, это сильно зависит от размера записи лога. Если он не велик, то и выигрыш будет незаметен. Не очень представляю себе например как будет распараллелен контроллером массива запрос на запись одной 8-килобайтной страницы лога при стандарном размере страйпа массива в 256К. Если поделитесь инфой\ссылкой буду очень благодарен. Кроме того имел в виду что поскольку запись в лог последовательная, то эти операции будут идти одна за другой без возможности одновременного выполнения на разных шпинделях.
Выйгрыш может быть в том случае, когда данные пишут паралельные транзакции, либо есть батарейка на кеш записи.

Тогда на контроллер будет идти поток записи последовательных секторов, и он будет этот поток распаралеливать на несколько дисков (т.е. в потоке ведь не будет ожидания записи 8 кб блока, там будет сразу много таких блоков в очереди на запись, вот он их и будет раскидывать на разные диски)

Конечно, если один сиквельный коннект будет в цикле делать инсёрты, и при этом кеша записи в рейд-контроллере нету, то большой рейд будет не быстрее (а може и медленнее) пары дисков в зеркале.
gang
Использование же кеша с размером массива никак не связано.
Я имел в виду кеш в контроллере массива. Как раз это ключевой момент для утилизации большого рейда. Даже последовательные транзакции будут писать блоки в этот кеш с огромной скоростью, а контроллер будет сбрасывать этот поток на большой массив дисков.
gang
Мое ИМХО, но потребность в индексах превышающих объем данных это не вполне нормально. Скорее походит на ошибки проектирования структуры данных.
Ну в принципе да, но бывают большие сложные поиски по обычным нормальным атрибутам... то есть в теории тут вроде ничего страшного нет.
Хотя согласен, нужно такие случаи специально исследовать - может быть ошибки проектирования структуры данных, а может просто элементарный бардак, когда разные программисты создают почти одинаковые индексы, хотя можно было бы обойтись меньшим количеством...
29 авг 12, 15:31    [13083151]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить