Конфигурация под MSSQL

Как создать сервер оптимальной конфигурации.

Модераторы: Trinity admin`s, Free-lance moderator`s

crypter
Junior member
Сообщения: 12
Зарегистрирован: 03 июл 2008, 09:49
Откуда: Самара

Конфигурация под MSSQL

Сообщение crypter » 03 июл 2008, 10:12

Доброго дня.

По-критикуйте пожалуйста конфигурацию:

Код: Выделить всё

- 2 * Intel Xeon Quad Core E5450 3.0 ГГц/12МБ/1333;
- 16 ГБ RAM (8*2);
- Adaptec RAID 5805 (512 МБ кеш, BBU);
- 10*HDD SAS 146 ГБ 15000 rpm;
- 10/100/1000 Мб Ethernet;
- 2 БП по 830 Вт;
- избыточное охлаждение (4 вентилятора);
- настольное исполнение.
ОС: Windows Server 2003 Enterprise Edition (IA-32).
Основная задача: MS SQL 2000 Enterprise Edition (IA-32), основной контроллер домена.

БД - НЕ 1С, размер БД 15 ГБ, прирастает на 10...12 ГБ в год, сезонная неоднородность нагрузки (зимой нагрузка выше, чем летом). Число пользователей - около 30, ожидаемый на перспективу (не менее 5 лет) максимум пользователей - 50.
Ожидаемый массив - RAID10 или RAID6. О том, что RAID6 для БД не лучший выбор, знаю, но прельщает высокая отказоустойчивость, да и разработчики нашей БД настаивают на таком варианте. Сам радею к RAID10 (8 - в массив, 2 - в горячий резерв).

Заранее благодарен :)

Аватара пользователя
Tert
Advanced member
Сообщения: 4233
Зарегистрирован: 19 янв 2003, 08:09
Откуда: Москва
Контактная информация:

Сообщение Tert » 03 июл 2008, 11:11

crypter
Нормальная конфигурация.
Только непонятно, зачем там диски по 146 ГБ, если можно обойтись и дисками по 73 ГБ.
Совет использовать под БД самый медленный вариант массива (RAID 6) - просто глупый.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 03 июл 2008, 11:13

1. Конфиг "в среднем по палате" выглядит как бы достаточным.
Но "избыточное охлаждение", "настольное исполнение" и прочее ничего не говорят о маме и корпусе  :D  
2. Для БД с ростом чуть ли не 100% в год использовать RAID6 - занятие, извините, для мазохистов. Так что я согласен в этом плане с Вами - правильнее использовать RAID10.

crypter
Junior member
Сообщения: 12
Зарегистрирован: 03 июл 2008, 09:49
Откуда: Самара

Сообщение crypter » 03 июл 2008, 12:12

спасибо за отзывы :)

сервер как бы брендовый - kraftway, но местный поставщик как-то неохотно делится информацией о начинке (это очень настораживает). выяснил, что мать с чипсетом Intel 5000P Blackford, про корпус постараюсь узнать. на контроллере настоял сам - мне предлагали LSI с кешем 128 МБ (маловато).
по дискам подумаю. это неплохой вариант снизить стоимость сервера и взять, например, диск в запас.
по RAID - вы меня окончательно убедили, соберу десятку.

Аватара пользователя
Tert
Advanced member
Сообщения: 4233
Зарегистрирован: 19 янв 2003, 08:09
Откуда: Москва
Контактная информация:

Сообщение Tert » 03 июл 2008, 13:06

crypter
А что там узнавать? Если это Крафт, то скорее всего будет следующая конфигурация:
1. Плата Intel S5000PSL
2. Корпус SC5400.

За объемом кэша на контроллерах лучше не гнаться. Часто увеличение кэша в два раза не дает особого прироста в скорости (особенно если контроллер работает только с одним массивом). Единственный реальный способ увеличения скорости работы дисковой системы - поставить больше дисков.

crypter
Junior member
Сообщения: 12
Зарегистрирован: 03 июл 2008, 09:49
Откуда: Самара

Сообщение crypter » 03 июл 2008, 13:56

Tert писал(а):crypter
За объемом кэша на контроллерах лучше не гнаться. Часто увеличение кэша в два раза не дает особого прироста в скорости (особенно если контроллер работает только с одним массивом). Единственный реальный способ увеличения скорости работы дисковой системы - поставить больше дисков.
а вот это интересно. я как-то думал, что большой объем кеша не помешает и производительность дисковой подсистемы достаточно сильно от него зависит. Сильна ли разница на контроллерах с кешем 256 МБ и 512 МБ?
еще вопрос, работаете ли вы в Самаре? если нет, то возможно ли заказать у вас сервер с доставкой. наконец, сколько может стоить у вас сервер с такой конфигурацией (бюджет - до 300000 руб.)?

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16650
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 03 июл 2008, 14:02

В Самаре нету (Москва-Питер-Екатеринбург), но доставку организовать можно. За деньги, но недорого.

Сам по себе размер кэша может дать эффект, но далеко не на всех задачах. Не стоит за этим гнаться - как уже отметили, от количества шпинделей эффект значительно больше. В конце концов на файберных дисковых системах, где десятки-сотни шпинделей, объем кэша обычно в районе 1-2-4ГБ на контроллер.

Аватара пользователя
Tert
Advanced member
Сообщения: 4233
Зарегистрирован: 19 янв 2003, 08:09
Откуда: Москва
Контактная информация:

Сообщение Tert » 03 июл 2008, 14:05

crypter
Варианты сервера отправил на почту.

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 07 июл 2008, 16:34

crypter писал(а):а вот это интересно. я как-то думал, что большой объем кеша не помешает и производительность дисковой подсистемы достаточно сильно от него зависит
Зависит. Но не всегда так, как мы думаем :)
http://sqlblog.com/blogs/linchi_shea/ar ... tions.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... -i-os.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... loads.aspx

Аватара пользователя
Stranger03
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 12979
Зарегистрирован: 14 ноя 2003, 16:25
Откуда: СПб, Екатеринбург
Контактная информация:

Сообщение Stranger03 » 09 июл 2008, 09:00

crypter писал(а):а вот это интересно. я как-то думал, что большой объем кеша не помешает и производительность дисковой подсистемы достаточно сильно от него зависит.
Для базы данных, у которой основная проблема - чтение и запись большого количества данных, физически не помещающихся в кеш любого контроллера (включая и серьезные массивы типа ДС4700), важны как раз не количество кеша контроллера, а бОльшее количество дисков, на которых размазаны данные.
еще вопрос, работаете ли вы в Самаре? если нет, то возможно ли заказать у вас сервер с доставкой. наконец, сколько может стоить у вас сервер с такой конфигурацией (бюджет - до 300000 руб.)?
Не сильно много, но думаю с 10-к клиентов в Самаре есть. С доставкой проблем нет.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 09 июл 2008, 11:04

Vadik писал(а):
crypter писал(а):а вот это интересно. я как-то думал, что большой объем кеша не помешает и производительность дисковой подсистемы достаточно сильно от него зависит
Зависит. Но не всегда так, как мы думаем :)
http://sqlblog.com/blogs/linchi_shea/ar ... tions.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... -i-os.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... loads.aspx
Угу. Смотрим:
Первая ссылка - Performance impact of controller cache: SQL Server large operations
1. Bulk Load - WB кэш рулит и педалит, оно и понятно.
2. SELECT - слегка cтранное.
По этой ссылке я нигде не увидел размер кэша самого SQL, вообще говоря. И не понял, где располагается лог SQL - на том же контроллере или где-то еще ? Он мог несколько добавить к общей записи.
Собственно, то, что внутренние контроллеры серверов не имеют столь продвинутых алгоритмов кэширования, как во внешних массивах - эт известно и понятно. Также понятно, что если тест производился после рестарта - и внешний контроллер не успел бы набрать статистики для оптимизации кэширования.
То есть имела место быть при этом тесте какая-то относительно мелкая запись, которую WB кэш на максимуме "съел" + относительная "тупость" read-ahead. Напомню, на тех же старых LSI read-ahead был оч простой: либо просто чтение следующего после запрошенного блока автоматом ("просто" read-ahead) либо - при хите чтение 2 блоков, при миссе - ничего не читает. Подозреваю, что с тех пор алгоритмы read-ahead внутренних контроллеров вряд ли изменились. Естественно, механизм ввода/вывода СУБД, который "знает", что и как надо предвыбирать, работает гораздо эффективнее "тупого" контроллерного.
3. UPDATE - ну тут все понятно :) WB он и в Африке WB.
И что собственно хотели тут доказать - мне непонятно.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 09 июл 2008, 11:11

Вторая ссылка: Performance impact of controller read cache: large sequential I/Os .
Для чего выбран блок 256 КБайт ? Современные СУБД обычно общаются с винтами несколько меньшими блоками. И по третьей ссылке цифирь счетчиков это подтверждает.
Поправка: я не увидел при написании этого поста, что он мерит не IOps, а МБ/с . Для чего ? Непонятно.
Последний раз редактировалось a_shats 09 июл 2008, 11:26, всего редактировалось 1 раз.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 09 июл 2008, 11:24

Третья ссылка: Performance impact of controller cache: SQL Server OLTP workloads
Как раз график наглядно и демонстрирует то, что я писал в предыдущем посте, про странности с Outstanding I/Os.
Примерно до сотни контроллеру тяжко.
Но это еще не все. Товарищ тестер то ли не нашел винтов, то ли еще что, но сама по себе видимая на графике эффективность WB кэша демонстрирует, что изрядная запись имеет место быть, а значит - надо было делать не 2 зеркала под базу и логи отдельно, а RAID10. И в этом случае кэш WB оказал бы несколько меньшее влияние на итоги тестирования :)
Есть еще интересные места:
For my tests, I sized the test to 100 warehouses that resulted in about 9GB of allocated storage space. And to ensure that the disk I/Os would be heavily exercised, I set the SQL Server buffer pool to 2GB.
Запомнили цифирь ? Кэш контроллера, напомню, составляет 512 МБ.
Strictly speaking, what I ran can't be called TPC-C because not all the stringent TPC-C rules were followed. For instance, to simplify the tests, I did not leave any think time or wait time between consecutive database calls.
Теперь предлагаю вспомнить цифирь обратно  :D  Вышеописанное означает, что тест работает примерно как IOMeter с отключенными Transfer Delay и Burst Length, т.е. кэш контроллера насмерть забивается :)

В целом - непонятно что тестер хотел продемонстрировать и зачем. Точнее понятно, что он хотел сказать, что "тупой" кэш на чтение внутреннего контроллера помогает хуже, чем "умный" кэш SQL (про объем коего он написал только в 3 тесте), но по мне - неубедительно как-то вышло  :D

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 09 июл 2008, 23:45

Первая ссылка - Performance impact of controller cache: SQL Server large operations
1. Bulk Load - WB кэш рулит и педалит, оно и понятно
Согласен
2. SELECT - слегка cтранное.
По этой ссылке я нигде не увидел размер кэша самого SQL, вообще говоря.
А какая, извините, разница, какого размера у сиквела buffer pool - сравниваются-то три варианта распределения кэша одного и того же контроллера на одном и том же сервере (т.е. с одним и тем же buffer pool)? Разницы тем более никакой, учитывая, что пункт начинается с
After the clean buffer pages were dropped
:wink:
И не понял, где располагается лог SQL - на том же контроллере или где-то еще ? Он мог несколько добавить к общей записи.
У сиквела нет лога. Лог есть у БД, коих на сиквеле несколько. Какую запись может генерировать чистый table scan select - затрудняюсь представить
Естественно, механизм ввода/вывода СУБД, который "знает", что и как надо предвыбирать, работает гораздо эффективнее "тупого" контроллерного
На то что страница, не нашедшаяся в buffer pool, вернется при чтении из кэша контроллера, в разы, если не на порядок, меньшего по размеру, расчитывать можно только закоренелым оптимистам. Какую бы мегалогику туда ни прошили :)
3. UPDATE - ну тут все понятно :) WB он и в Африке WB.
так точно
И что собственно хотели тут доказать - мне непонятно
А то, что большой кэш на чтение ни в одном из сценариев ничего, кроме ухудшения результатов, ничего не дал, ни на какие мысли не наводит?  :wink:

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 09 июл 2008, 23:52

a_shats писал(а):Вторая ссылка: Performance impact of controller read cache: large sequential I/Os .
Для чего выбран блок 256 КБайт ? Современные СУБД обычно общаются с винтами несколько меньшими блоками.
Я за все современные СУБД говорить не буду. А у сиквела 2005 в enterprise редакции io size при упреждающем чтении (read-ahead) варьируется от 128 до 1024 страниц. Размер страницы Вы знаете - вот и посчитайте :D

Ответить

Вернуться в «Серверы - Конфигурирование»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 21 гость