8-ми процессорный монстр или .......

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

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

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

8-ми процессорный монстр или .......

Сообщение Zigzug » 25 ноя 2002, 16:46

Привет!

Дано: 4-х ксеоновый сервер (4Gb RAM, Mylex 352 64Mb) производства компании Тринити :lol:
На нем MS2000SRV+SQL2000 Enterprise.
И базы примерно 20Gb. Пользователей примерно 80-90.

Нагрузка на сервер достаточно большая. Если смотреть в Диспетчере Задач, то на всех 4-х процах загрузка в основном 50-60%, а периодически 100% и это не пик, а достаточно продолжительное время. Соответственно пользователи начинают ныть, что у них все тормозит.
А в переспективе планируется увеличение кол-ва и объема баз, ну и пользователей тоже.

Надо: сделать так, что-бы пользователи не ныли, а сервер начал "летать".
Покупать subj? Делать кластер? Переходить на *nix+Oracle? А может сразу на SUN?

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

Сообщение a_shats » 25 ноя 2002, 18:30

Хм. Вопрос, конечно, к сотрудникам Тринити, но и я - хоть попробую ответить... ;)
1.
Дано: 4-х ксеоновый сервер (4Gb RAM...
....
И базы примерно 20Gb.
Оперативку нарастить не менее, чем до 10 Гб (50% от объема баз). Дать MSSQL весь объем памяти минус то, что необходимо для работы ОС (причем - лучше зафиксировать выделенную для MSSQL память - есть такая опция в настройках сервера). Включить Use Windows NT fibers. И т.д. - в общем, настроить как следует сам SQL- сервер - в первую очередь.
2. Непонятно - какой уровень RAID ? Сколько есть винчестеров ? Возможно, может помочь переход (с доукомплектацией винтами, скорее всего) на уровень RAID с большей производительностью. Дополнительный эффект может дать разнесение файлов БД (данных и журнала транзакций) на разные физические носители (массивы RAID в Вашем случае).
Опять же - непонятно, какая нагрузка наиболее характерна для Вашей базы - чтение и запись "вразброс" (на сборе данных) или массированное чтение (при генерации аналитики) ?
3. Какие Ксеоны ? PIII Xeon или Xeon MP ? Тактовая частота ?
Но - в любом случае - такая нагрузка на процессоры при таком объеме баз говорит о том, что очень интенсивно идет работа с относительно небольшими блоками данных, что открывает простор для профилирования самой базы (даже без кардинальных изменений в структуре - например, найдите наиболее часто выполняющиеся запросы, проверьте их планы, постройте дополнительные индексы так, чтобы эти запросы выполнялись только по индексированным полям - получите некислый рост скорости выполнения запросов и значительное снижение нагрузки на процессоры). Для хорошо отстроенной и отпрофилированной базы нагрузка на процессоры не должна превышать 50-60%.
Кроме того: эффект дает разнесение сбора данных и аналитики на разные сервера (естественно, с репликацией между ними).
Кстати говоря: БД с "плохой" (нерациональной) структурой никакой монстр не поможет.
Профилировать и еще раз профилировать.
Переходить на *nix+Oracle ?
:shock:
Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ? Или Вы считаете, что перенести структуру и 20 Гб данных между несовместимыми между собой SQL-серверами так просто ? Ой, в общем.

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 26 ноя 2002, 10:27

>Оперативку нарастить не менее, чем до 10 Гб (50% от объема баз).

Здесь вот какой момент - на сервере установлен WIN 2000 Server (лицензионный), а он максимально держит 4Gb. Если сативть Advanced Server - до 8Gb. Тут мы все равно частично заделываем дыру по памяти, но с учетом дальнейшей переспективы роста и этого мало. Далее идет Datacenter Server (до 64Gb), но как я понимаю этот продукт так просто не купишь. Кстати наш аппарат называется SuperServer 8050.

>Дать MSSQL весь объем памяти минус то, что необходимо для работы ОС (причем - лучше зафиксировать выделенную для MSSQL память - есть такая опция в настройках сервера).

Пробовали. Вы будете смеяться, но с динамическим выделением памяти работает немного быстрее.

>Включить Use Windows NT fibers. И т.д. - в общем, настроить как следует сам SQL- сервер - в первую очередь.

Включено и настроено.

>Непонятно - какой уровень RAID ? Сколько есть винчестеров ? Возможно, может помочь переход (с доукомплектацией винтами, скорее всего) на уровень RAID с большей производительностью.

В системе установлен Mylex AcceleRAID 352 64Mb RAM. 3 диска IBM DDYS 9Gb (RAID 5) под систему, программы и частично базы SQL + 3 иска IBM DDYS 32Gb (RAID 5) только базы + 1HDD в HOT Spare.

Характер работы с БД - запись и чтение "вразброс".

>Какие Ксеоны ? PIII Xeon или Xeon MP ? Тактовая частота ?

XEON PIII 550 4 шт.

>Кроме того: эффект дает разнесение сбора данных и аналитики на разные сервера (естественно, с репликацией между ними).

Да, это уже сделано. Раньше у нас был один тормозящий сервер, а теперь 2 :cry:

>Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ?

У нас свой штат программистов и их эти тормоза тож достали. :lol:

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

Сообщение a_shats » 26 ноя 2002, 11:05

Zigzug писал(а):>
Здесь вот какой момент - на сервере установлен WIN 2000 Server (лицензионный), а он максимально держит 4Gb. Если сативть Advanced Server - до 8Gb.
Мда...
С учетом дальнейшей перспективы роста - имхо, Win+MSSQL (даже Datacenter) такое вряд ли потянет. С учетом того, что у Вас команда программеров своя - попытайтесь хотя бы сориентироваться по ценам на связку: что-то из Sun+Solaris+Oracle(просто - проверенное решение, потому и предлагаю). На самом деле. Ваша база, судя по размерам, требует каких-то кардинальных по производительности решений.
Пробовали. Вы будете смеяться, но с динамическим выделением памяти работает немного быстрее.
Смеяться не буду: при Вашем объеме базы наличие постоянно выделенной под SQL оперативки в некоторых ситуациях может вызвать серьезный свап.
Включено и настроено.
В системе установлен Mylex AcceleRAID 352 64Mb RAM. 3 диска IBM DDYS 9Gb (RAID 5) под систему, программы и частично базы SQL + 3 иска IBM DDYS 32Gb (RAID 5) только базы + 1HDD в HOT Spare.
Характер работы с БД - запись и чтение "вразброс".
XEON PIII 550 4 шт.
Если бы в данной ситуации возможно было бы улучшить производительность "косметическими" улучшениями, я бы сказал следующее:
1. Для таких объемов и такой системы RAID - контроллер может оказаться слабоват. Нужно что-то с более серьезной производительностью. Что-то типа E2000 или внешнего FC RAID контроллера.
2. Одиночный RAID 5 - не Enterprise решение, скорее, базовое. Вам нужно уже что-то калибра RAID 10 - да с разнесением базы на пару массивов.
3. Xeon III 550 : сам по себе хорош. Но, напомню: FSB 3-го Ксеона - 100 МГц. Шина памяти - тоже (скорее всего - чипсет синхронный).
И все-таки: загрузка процессоров на 100%, видимая ОС (а их - четыре!), говорит о том, что все данные, необходимые для текущих дел, находятся в оперативке.
Возможно, это - как раз результат усилий программистов, пытавшихся как можно эффективнее размещать данные в явно недостаточном для такой базы объеме ОЗУ.
Да, это уже сделано. Раньше у нас был один тормозящий сервер, а теперь 2 :cry:
Хм. Стало быть, все-таки есть простор для отладки и профилирования:
использование OLAP для аналитики, оптимизация базы под сбор и т.п.
И последнее: если не секрет - что за задачи, под которые данная база построена ? Хотя бы - к какому классу относятся ? Может быть, имеет смысл использовать какие-то известные, проверенные решения для данной задачи, нежели городить свое ?
По идее, раз у Вас в конторе есть штат программеров - вот пусть они и определятся - какими аппаратными и программными средствами эффективнее всего данную задачу решать.Они в ней живут - потому их взгляд на проблему может оказаться наиболее точным.
На такой задаче "косметические" улучшения вряд ли принесут пользу (может быть и будет небольшой "мгновенный" эффект от заплаток, но в будущем - заплатки потянут за собой проблемы...)

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 26 ноя 2002, 12:21

С учетом дальнейшей перспективы роста - имхо, Win+MSSQL (даже Datacenter) такое вряд ли потянет.
Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю. :oops:
что-то из Sun+Solaris+Oracle(просто - проверенное решение, потому и предлагаю)
А можно подробнее? Какое железо, какой софт, может примерные цены, поставщики? Если это оффтопик, то можно на мыло...
Слово Sun, как и слово Cisco у меня ассоциируется с боооольшими деньгами....
Хм. Стало быть, все-таки есть простор для отладки и профилирования:
использование OLAP для аналитики, оптимизация базы под сбор и т.п.
И последнее: если не секрет - что за задачи, под которые данная база построена ? Хотя бы - к какому классу относятся ? Может быть, имеет смысл использовать какие-то известные, проверенные решения для данной задачи, нежели городить свое ?
Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.
А задача этой БД - сбор, учет, хранение информации по клиентам. В качестве клиентов выступают частные лица. Соответственно по каждому клиенту нужно иметь информацию по его адресу, что, когда и в каком количестве он купил, когда и как доставили заказ, когда и как оплатил или не оплатил - в общем, масса информации.
Специфика работы нашей конторы не позволяет использовать уже что-то готовое. Идея чучхе :?

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 26 ноя 2002, 12:38

Zigzug писал(а):В системе установлен Mylex AcceleRAID 352 64Mb RAM. 3 диска IBM DDYS 9Gb (RAID 5) под систему, программы и частично базы SQL + 3 иска IBM DDYS 32Gb (RAID 5) только базы + 1HDD в HOT Spare.

Характер работы с БД - запись и чтение "вразброс".
Какая политика кеширования?
Хорошо бы логи на отдельный контроллер повесить, например на нынешний - пару-четвёрку дисков в 1/10 WB. BBU есть, надеюсь?
А базу на массив из большого числа возможно более быстрых дисков.
Либо на твёрдотельные диски.

Но если локальная часть базы больше 2-3ГБ, то радикально поможет только 64-ёхбитная версия MS-SQL или миграция на другие платформы 64.

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 26 ноя 2002, 12:45

Zigzug писал(а):Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю. :oops:

Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.
Первому кластер как мёртвому припарки, второму может и помочь.
А который тормозит сильнее? :)

Аватара пользователя
Dmitry
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 861
Зарегистрирован: 22 авг 2002, 16:12
Откуда: St.Petersburg
Контактная информация:

Сообщение Dmitry » 26 ноя 2002, 12:45

Теоретичиски возможны следующие улучшения:
в порядке эфективности
1. установка MS Advanced Server и памяти до 8 GB
2. переход на RAID 0+1
3. замена всех дисков 10000rpm на 15000rpm
4. замена Mylex AcceleRAID 352/64 на AcceleRAID 600/128
5. замена CPU на 700MHz cache 2MB

Естественно это все дорого и тупиковое решение при дальнейшем росте. Выход один - новая платформа на базе XEON MP 1.6 GHz c L3 cache 1MB или подождать доступность решений на XEON MP 2GHz c L3 cache 2MB.

Думаю переход на Solaris + Oracle еще сложнее. Смена идиологии всегда дороже. Если найдете силы - Удачи!

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

Сообщение a_shats » 26 ноя 2002, 14:19

Zigzug писал(а): Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю. :oops:
Кластеры в W2K - только отказоустойчивые, вычислительные - это в *nix. Обратитесь к CyberDrake, он Вам подробнее разъяснит. Кроме того, кластер - вычислительный - пригоднее для хорошо параллелящихся задач. БД (как минимум аналитика) - не есть таковая задача. Сбор данных - там да, чем выше мощь системы в целом, тем меньше время отклика.
Хотя можно подумать и над вариантами: MSSQL умеет работать в кластере. Насколько эффективно ? Не знаю, не пробовал.
А можно подробнее? Какое железо, какой софт, может примерные цены, поставщики? Если это оффтопик, то можно на мыло...
Слово Sun, как и слово Cisco у меня ассоциируется с боооольшими деньгами....
Правильно ассоциируется ;) . Если взять "из пальца" и при условии, что все лицензионное - может потянуть что-то около 150-200 т. баксов. Если Вас такой порядок цен устроит - то можно продолжить обсуждение. Нет - тогда смотрите все-таки в сторону х86 . Дешевых RISC-серверов, способных потянуть такую задачу, имхо, нет.
Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.
Хм. Конфигурации сервера для сбора информации и аналитического должны бы довольно-таки серьезно отличаться: если для первого характерны чтение и запись "вразброс", то для второго - массированное, практически последовательное чтение - запись значительно реже. Т.е.- как минимум - для первого важнее объем дисковой подсистемы и ОЗУ, для второго - прозводительность дисковой и процессорная мощь.
А задача этой БД - сбор, учет, хранение информации по клиентам. В качестве клиентов выступают частные лица. Соответственно по каждому клиенту нужно иметь информацию по его адресу, что, когда и в каком количестве он купил, когда и как доставили заказ, когда и как оплатил или не оплатил - в общем, масса информации.
Типичная задача OLTP, только - толстая ;) (по моим скромным региональным понятиям, ессно).
Специфика работы нашей конторы не позволяет использовать уже что-то готовое. Идея чучхе :?
Нуу... Хозяин - барин ;)

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 26 ноя 2002, 14:30

a_shats писал(а):БД (как минимум аналитика) - не есть таковая задача. Сбор данных - там да, чем выше мощь системы в целом, тем меньше время отклика.
Аналитика замечательно параллелится, если запрос не один 8)
А с транзакциями как раз всё хуже...

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

Сообщение a_shats » 26 ноя 2002, 14:32

Так.
Если не решитесь менять идеологию ;), то:
- 8 процессорная платформа и Datacenter - иначе через годик придется вернуться к данной проблеме.
Как сделать (имхо):
- для начала, возьмите 8-процессорную платформу (именно - под сбор данных) с 4-мя установленными процессорами, 12 Гб ОЗУ (с возможностью расширения до 24), пару hot-swap HDD небольшой емкости под систему, производительный внешний RAID с 5 HDD (емкость каждого должна быть не менее размера базы, умноженного на 1,5 ;) - т.е. в Вашем случае, 36 Гб) - делаем RAID10+1 HDD в hot-spare.
- устанавливаем, настраиваем,запускаем: первую неделю - ничего не меняем (!), только, при помощи всех доступных инструментов, ищем узкие места
-в конце первой недели делаем все, что можно решить программно (на основании накопленных и проанализированных данных - тюнинг ОС и SQL-сервера).
- еще неделю - смотрим: есть ли еще проблемы с производительностью. Опять ничего в течение недели не меняем. Убеждаемся во всех предположениях об узких местах на железе.
- в конце недели: добиваем железо, исходя из накопленных данных, с запасом по объему и производительности. Еще неделю - смотрим.
- в конце недели - выполняем окончательный тюнинг всего. После этого можно считать задачу выполненной.
Естественно, весь процесс пуска (особенно - тюнинг и подбор железа) лучше проводить с помощью специалистов фирмы-поставщика сервера. Собранные вами данные об узких местах иногда для Вас могут значить одно, для спеца по данному конкретному железу - другое.
Затем - по аналитическому серверу - процесс тот же.
Если нужны доп. соображения, детали - пишите. Чем можем, как говорится...

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

Сообщение a_shats » 26 ноя 2002, 14:39

ВТБ! писал(а): Аналитика замечательно параллелится, если запрос не один 8)
А с транзакциями как раз всё хуже...
Неа ;)
OLAP можно разбить на столько взаимонезависимых нитей, сколько есть запросов, не зависящих от результатов других запросов ( а вот это как раз - дело, имхо, достаточно редкое)...
С транзакциями проще - на каждое клиентское подключение создается поток или нить (зависит от конкретного SQL- сервера). Да если еще учесть, что пользовательские транзакции не слишком активны (нагрузка возникает фактически только при select/fetch или commit/rollback)...Самое дело - для HyperThreading'а. ;)
Последний раз редактировалось a_shats 26 ноя 2002, 14:57, всего редактировалось 1 раз.

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 26 ноя 2002, 14:50

для начала, возьмите 8-процессорную платформу (именно - под сбор данных) с 4-мя установленными процессорами, 12 Гб ОЗУ (с возможностью расширения до 24), пару hot-swap HDD небольшой емкости под систему, производительный внешний RAID с 5 HDD (емкость каждого должна быть не менее размера базы, умноженного на 1,5 - т.е. в Вашем случае, 36 Гб) - делаем RAID10+1 HDD в hot-spare.
Вот это меня и смущает. Сколько будет стоить такой сервак? Ну а с нашими запросами этого на год и хватит.... А дальше что? :cry:

Может сразу эти деньги вложить в sun? :idea:
Вопрос даже вот так можно поставить - а какие высокопроизводительные платформы под нашу задачу реально доступны в Москве?
И кто что посоветует?

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 26 ноя 2002, 15:08

a_shats писал(а): OLAP можно разбить на столько взаимонезависимых нитей, сколько есть запросов, не зависящих от результатов других запросов ( а вот это как раз - дело, имхо, достаточно редкое)...
Я имел ввиду независимые запросы по статичной базе.
a_shats писал(а):С транзакциями проще...
Самое дело - для HyperThreading'а. ;)
Речь шла о параллелизме между узлами кластера.

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

Сообщение a_shats » 26 ноя 2002, 15:29

Zigzug писал(а): Может сразу эти деньги вложить в sun? :idea:
Может. Но - осторожно: никто не гарантирует Вам, что стартовой (той в которой Вам поставят) конфигурации Сановского сервера хватит под Вашу базу на всю оставшуюся жизнь. С одной стороны, Саны масштабируются лучше, чем x86. С другой - недешево это. Порядок цен я назвал.
Подробнее по серверам Sun можно посмотреть здесь:http://www.ixbt.com/cpu/sun-solutions.shtml
А х86 будет сильно дешевле ;)

Ответить

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