P4 Xeon 2400Mhz 512kb для MS SQL
Модераторы: Trinity admin`s, Free-lance moderator`s
P4 Xeon 2400Mhz 512kb для MS SQL
Проблема в следующем :
Имеется сервер HP LH3000 с 2 камнями PIII 800Mhz , раз в месяц (примерно) на нем запускаются сохраненные процедуры, которые перерасчитывают базу (размер которой сейчас~10Gb). Все это дело сечас происходит целые сутки.
Решили ускорить. Т.е. купить новый сервер. То что использовать надо рэйд и винты быстрые 15K это понятно из предыдущих форумов.
Но вот камни: Ходят слухи , что на серверных платформах под SQL 6.5 пеньки четвертые никакого выйгрыша не дают. И что в некоторых случаях работают даже медленнее.
Дорогие коллеги немогли бы вы просветить меня в этом....
Заранее благодарен
gizar
Имеется сервер HP LH3000 с 2 камнями PIII 800Mhz , раз в месяц (примерно) на нем запускаются сохраненные процедуры, которые перерасчитывают базу (размер которой сейчас~10Gb). Все это дело сечас происходит целые сутки.
Решили ускорить. Т.е. купить новый сервер. То что использовать надо рэйд и винты быстрые 15K это понятно из предыдущих форумов.
Но вот камни: Ходят слухи , что на серверных платформах под SQL 6.5 пеньки четвертые никакого выйгрыша не дают. И что в некоторых случаях работают даже медленнее.
Дорогие коллеги немогли бы вы просветить меня в этом....
Заранее благодарен
gizar
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Попробую что-нибудь накидать: Все имхо.
Что касательно P4 Xeon'ов (DP и MP): как раз на MSSQL выигрыш в производительности от них есть. И - неслабый. Отчего ?
1. Шина: сравните 400 MHz Xeon'ов и 100/133 PIII (и 100 - PIII Xeon).
MSSQL создает весьма и весьма серьезную нагрузку на процессор-память(он достаточно хорошо умеет кэшировать блоки БД, причем-в обход файлового кэша ОС), и тут преимущество скоростной шины видно в полный рост .
2. Частота: 1,4-1,6 МГц Ксеоны с 512 Кб кэшем имеют малое преимущество перед III-ми. Причина: NetBurst (точнее, длинный конвейер) . Дело в том, что код, который исполняется SQL (код самого SQL)-сплошные ветвления, и рестарт конвейера из-за ошибочного предсказания перехода может происходить довольно часто.
Начиная с 1,8 - 2 Ггц: я не специалист по процессорам, но могу лишь весьма субъективно сказать (в смысле - по собственным ощущениям) : на таких частотах при работе с БД Ксеоны (и DP, и MP) начинают серьезно обходить PIII/|PIII Xeon.
3. HyperThreading: это когда 1 Ксеон прикидывается двумя "виртуальными" процессорами - для ОС. Суть в том, что очень многие исполнительные устройства в процессорах многократно продублированы, и в большинстве случаев (кроме пиковых нагрузок и работы с данными, помещающимися в кэши L1/L2) часть из них простаивает. Как раз HT позволяет задействовать "простаивающие" устройства. При этом единственный минус - нужно очень некислая пропускная шины между памятью и процессором - "виртуальные" процессоры без какого-либо видимого (perfmon'ом и task manager'ом) снижения производительности молотят данные весьма реально - даже при пиковых нагрузках. Что касается памяти - практически во всех мамах под Xeon DP/MP - двухканальная DDR266 (т.е., особенных проблем тут нет).
4. Понятно, что движки БД не оптимизируются под SSE Но: PIII- уже практически мертв (будет снят с производства где-то в 3-м квартале следующего года). Вы хотите через пару лет искать spares kits для этой платформы ?
Что касательно Вашей базы:
Такую тяжелую вещь лучше разнести на 2 как минимум 2-процессорных сервера: на одном - сбор данных, на другом - аналитика и перерасчет. Если хотите, прикину конфигурацию. Кстати: было бы неплохо бы померить хотя бы чем-то типа perfmon'а характерные нагрузки на процессоры(средний процент загрузки днем и при перерасчете), память (занятость и количество отказов страницы в обоих случаях), нагрузку на сеть и винты (байт/сек на чтение и запись (отправленных/полученных ) отдельно для обоих случаев). И средний рост базы в месяц. Тогда - будет проще прикидывать .
Что касательно P4 Xeon'ов (DP и MP): как раз на MSSQL выигрыш в производительности от них есть. И - неслабый. Отчего ?
1. Шина: сравните 400 MHz Xeon'ов и 100/133 PIII (и 100 - PIII Xeon).
MSSQL создает весьма и весьма серьезную нагрузку на процессор-память(он достаточно хорошо умеет кэшировать блоки БД, причем-в обход файлового кэша ОС), и тут преимущество скоростной шины видно в полный рост .
2. Частота: 1,4-1,6 МГц Ксеоны с 512 Кб кэшем имеют малое преимущество перед III-ми. Причина: NetBurst (точнее, длинный конвейер) . Дело в том, что код, который исполняется SQL (код самого SQL)-сплошные ветвления, и рестарт конвейера из-за ошибочного предсказания перехода может происходить довольно часто.
Начиная с 1,8 - 2 Ггц: я не специалист по процессорам, но могу лишь весьма субъективно сказать (в смысле - по собственным ощущениям) : на таких частотах при работе с БД Ксеоны (и DP, и MP) начинают серьезно обходить PIII/|PIII Xeon.
3. HyperThreading: это когда 1 Ксеон прикидывается двумя "виртуальными" процессорами - для ОС. Суть в том, что очень многие исполнительные устройства в процессорах многократно продублированы, и в большинстве случаев (кроме пиковых нагрузок и работы с данными, помещающимися в кэши L1/L2) часть из них простаивает. Как раз HT позволяет задействовать "простаивающие" устройства. При этом единственный минус - нужно очень некислая пропускная шины между памятью и процессором - "виртуальные" процессоры без какого-либо видимого (perfmon'ом и task manager'ом) снижения производительности молотят данные весьма реально - даже при пиковых нагрузках. Что касается памяти - практически во всех мамах под Xeon DP/MP - двухканальная DDR266 (т.е., особенных проблем тут нет).
4. Понятно, что движки БД не оптимизируются под SSE Но: PIII- уже практически мертв (будет снят с производства где-то в 3-м квартале следующего года). Вы хотите через пару лет искать spares kits для этой платформы ?
Что касательно Вашей базы:
Такую тяжелую вещь лучше разнести на 2 как минимум 2-процессорных сервера: на одном - сбор данных, на другом - аналитика и перерасчет. Если хотите, прикину конфигурацию. Кстати: было бы неплохо бы померить хотя бы чем-то типа perfmon'а характерные нагрузки на процессоры(средний процент загрузки днем и при перерасчете), память (занятость и количество отказов страницы в обоих случаях), нагрузку на сеть и винты (байт/сек на чтение и запись (отправленных/полученных ) отдельно для обоих случаев). И средний рост базы в месяц. Тогда - будет проще прикидывать .
Огромное спасибо за такой обзорный ответ...
В принципе все понятно. Один вопрос еще возник по поводу пункта:
"Что касательно Вашей базы:
Такую тяжелую вещь лучше разнести на 2 как минимум 2-процессорных сервера: на одном - сбор данных, на другом - аналитика и перерасчет. Если хотите, прикину конфигурацию. Кстати: было бы неплохо бы померить хотя бы чем-то типа perfmon'а характерные нагрузки на процессоры(средний процент загрузки днем и при перерасчете), память (занятость и количество отказов страницы в обоих случаях), нагрузку на сеть и винты (байт/сек на чтение и запись (отправленных/полученных ) отдельно для обоих случаев). И средний рост базы в месяц. Тогда - будет проще прикидывать ."
Чем можно было бы все это померить? Нельзя ли поподробней, и если можно, то где этот инструмент достать... ?
P.S.: а по поводу базы, то за год ,т.е. 12 мес. она выросла на 4 Gb, следовательно в месяц ~ 333ЬMb
Заранее благодарен за ответ
gizar
В принципе все понятно. Один вопрос еще возник по поводу пункта:
"Что касательно Вашей базы:
Такую тяжелую вещь лучше разнести на 2 как минимум 2-процессорных сервера: на одном - сбор данных, на другом - аналитика и перерасчет. Если хотите, прикину конфигурацию. Кстати: было бы неплохо бы померить хотя бы чем-то типа perfmon'а характерные нагрузки на процессоры(средний процент загрузки днем и при перерасчете), память (занятость и количество отказов страницы в обоих случаях), нагрузку на сеть и винты (байт/сек на чтение и запись (отправленных/полученных ) отдельно для обоих случаев). И средний рост базы в месяц. Тогда - будет проще прикидывать ."
Чем можно было бы все это померить? Нельзя ли поподробней, и если можно, то где этот инструмент достать... ?
P.S.: а по поводу базы, то за год ,т.е. 12 мес. она выросла на 4 Gb, следовательно в месяц ~ 333ЬMb
Заранее благодарен за ответ
gizar
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 24 гостя