8-ми процессорный монстр или .......
Модераторы: Trinity admin`s, Free-lance moderator`s
8-ми процессорный монстр или .......
Привет!
Дано: 4-х ксеоновый сервер (4Gb RAM, Mylex 352 64Mb) производства компании Тринити
На нем MS2000SRV+SQL2000 Enterprise.
И базы примерно 20Gb. Пользователей примерно 80-90.
Нагрузка на сервер достаточно большая. Если смотреть в Диспетчере Задач, то на всех 4-х процах загрузка в основном 50-60%, а периодически 100% и это не пик, а достаточно продолжительное время. Соответственно пользователи начинают ныть, что у них все тормозит.
А в переспективе планируется увеличение кол-ва и объема баз, ну и пользователей тоже.
Надо: сделать так, что-бы пользователи не ныли, а сервер начал "летать".
Покупать subj? Делать кластер? Переходить на *nix+Oracle? А может сразу на SUN?
Дано: 4-х ксеоновый сервер (4Gb RAM, Mylex 352 64Mb) производства компании Тринити
На нем MS2000SRV+SQL2000 Enterprise.
И базы примерно 20Gb. Пользователей примерно 80-90.
Нагрузка на сервер достаточно большая. Если смотреть в Диспетчере Задач, то на всех 4-х процах загрузка в основном 50-60%, а периодически 100% и это не пик, а достаточно продолжительное время. Соответственно пользователи начинают ныть, что у них все тормозит.
А в переспективе планируется увеличение кол-ва и объема баз, ну и пользователей тоже.
Надо: сделать так, что-бы пользователи не ныли, а сервер начал "летать".
Покупать subj? Делать кластер? Переходить на *nix+Oracle? А может сразу на SUN?
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Хм. Вопрос, конечно, к сотрудникам Тринити, но и я - хоть попробую ответить...
1.
2. Непонятно - какой уровень RAID ? Сколько есть винчестеров ? Возможно, может помочь переход (с доукомплектацией винтами, скорее всего) на уровень RAID с большей производительностью. Дополнительный эффект может дать разнесение файлов БД (данных и журнала транзакций) на разные физические носители (массивы RAID в Вашем случае).
Опять же - непонятно, какая нагрузка наиболее характерна для Вашей базы - чтение и запись "вразброс" (на сборе данных) или массированное чтение (при генерации аналитики) ?
3. Какие Ксеоны ? PIII Xeon или Xeon MP ? Тактовая частота ?
Но - в любом случае - такая нагрузка на процессоры при таком объеме баз говорит о том, что очень интенсивно идет работа с относительно небольшими блоками данных, что открывает простор для профилирования самой базы (даже без кардинальных изменений в структуре - например, найдите наиболее часто выполняющиеся запросы, проверьте их планы, постройте дополнительные индексы так, чтобы эти запросы выполнялись только по индексированным полям - получите некислый рост скорости выполнения запросов и значительное снижение нагрузки на процессоры). Для хорошо отстроенной и отпрофилированной базы нагрузка на процессоры не должна превышать 50-60%.
Кроме того: эффект дает разнесение сбора данных и аналитики на разные сервера (естественно, с репликацией между ними).
Кстати говоря: БД с "плохой" (нерациональной) структурой никакой монстр не поможет.
Профилировать и еще раз профилировать.
Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ? Или Вы считаете, что перенести структуру и 20 Гб данных между несовместимыми между собой SQL-серверами так просто ? Ой, в общем.
1.
Оперативку нарастить не менее, чем до 10 Гб (50% от объема баз). Дать MSSQL весь объем памяти минус то, что необходимо для работы ОС (причем - лучше зафиксировать выделенную для MSSQL память - есть такая опция в настройках сервера). Включить Use Windows NT fibers. И т.д. - в общем, настроить как следует сам SQL- сервер - в первую очередь.Дано: 4-х ксеоновый сервер (4Gb RAM...
....
И базы примерно 20Gb.
2. Непонятно - какой уровень RAID ? Сколько есть винчестеров ? Возможно, может помочь переход (с доукомплектацией винтами, скорее всего) на уровень RAID с большей производительностью. Дополнительный эффект может дать разнесение файлов БД (данных и журнала транзакций) на разные физические носители (массивы RAID в Вашем случае).
Опять же - непонятно, какая нагрузка наиболее характерна для Вашей базы - чтение и запись "вразброс" (на сборе данных) или массированное чтение (при генерации аналитики) ?
3. Какие Ксеоны ? PIII Xeon или Xeon MP ? Тактовая частота ?
Но - в любом случае - такая нагрузка на процессоры при таком объеме баз говорит о том, что очень интенсивно идет работа с относительно небольшими блоками данных, что открывает простор для профилирования самой базы (даже без кардинальных изменений в структуре - например, найдите наиболее часто выполняющиеся запросы, проверьте их планы, постройте дополнительные индексы так, чтобы эти запросы выполнялись только по индексированным полям - получите некислый рост скорости выполнения запросов и значительное снижение нагрузки на процессоры). Для хорошо отстроенной и отпрофилированной базы нагрузка на процессоры не должна превышать 50-60%.
Кроме того: эффект дает разнесение сбора данных и аналитики на разные сервера (естественно, с репликацией между ними).
Кстати говоря: БД с "плохой" (нерациональной) структурой никакой монстр не поможет.
Профилировать и еще раз профилировать.
Переходить на *nix+Oracle ?
Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ? Или Вы считаете, что перенести структуру и 20 Гб данных между несовместимыми между собой SQL-серверами так просто ? Ой, в общем.
>Оперативку нарастить не менее, чем до 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
>Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ?
У нас свой штат программистов и их эти тормоза тож достали.
Здесь вот какой момент - на сервере установлен 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
>Сорри, но: база и приложения под нее разрабатывались непосредственно у Вас ? Или у Вас такой хороший контакт с разработчиками, что они "за бесплатно" переколбасят 20 Гб базу под Оракл ?
У нас свой штат программистов и их эти тормоза тож достали.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Мда...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
использование OLAP для аналитики, оптимизация базы под сбор и т.п.
И последнее: если не секрет - что за задачи, под которые данная база построена ? Хотя бы - к какому классу относятся ? Может быть, имеет смысл использовать какие-то известные, проверенные решения для данной задачи, нежели городить свое ?
По идее, раз у Вас в конторе есть штат программеров - вот пусть они и определятся - какими аппаратными и программными средствами эффективнее всего данную задачу решать.Они в ней живут - потому их взгляд на проблему может оказаться наиболее точным.
На такой задаче "косметические" улучшения вряд ли принесут пользу (может быть и будет небольшой "мгновенный" эффект от заплаток, но в будущем - заплатки потянут за собой проблемы...)
Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю.С учетом дальнейшей перспективы роста - имхо, Win+MSSQL (даже Datacenter) такое вряд ли потянет.
А можно подробнее? Какое железо, какой софт, может примерные цены, поставщики? Если это оффтопик, то можно на мыло...что-то из Sun+Solaris+Oracle(просто - проверенное решение, потому и предлагаю)
Слово Sun, как и слово Cisco у меня ассоциируется с боооольшими деньгами....
Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.Хм. Стало быть, все-таки есть простор для отладки и профилирования:
использование OLAP для аналитики, оптимизация базы под сбор и т.п.
И последнее: если не секрет - что за задачи, под которые данная база построена ? Хотя бы - к какому классу относятся ? Может быть, имеет смысл использовать какие-то известные, проверенные решения для данной задачи, нежели городить свое ?
А задача этой БД - сбор, учет, хранение информации по клиентам. В качестве клиентов выступают частные лица. Соответственно по каждому клиенту нужно иметь информацию по его адресу, что, когда и в каком количестве он купил, когда и как доставили заказ, когда и как оплатил или не оплатил - в общем, масса информации.
Специфика работы нашей конторы не позволяет использовать уже что-то готовое. Идея чучхе
Какая политика кеширования?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.
Первому кластер как мёртвому припарки, второму может и помочь.Zigzug писал(а):Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю.
Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.
А который тормозит сильнее?
- Dmitry
- Сотрудник Тринити
- Сообщения: 867
- Зарегистрирован: 22 авг 2002, 16:12
- Откуда: St.Petersburg
- Контактная информация:
Теоретичиски возможны следующие улучшения:
в порядке эфективности
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 еще сложнее. Смена идиологии всегда дороже. Если найдете силы - Удачи!
в порядке эфективности
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
- Откуда: Москва
- Контактная информация:
Кластеры в W2K - только отказоустойчивые, вычислительные - это в *nix. Обратитесь к CyberDrake, он Вам подробнее разъяснит. Кроме того, кластер - вычислительный - пригоднее для хорошо параллелящихся задач. БД (как минимум аналитика) - не есть таковая задача. Сбор данных - там да, чем выше мощь системы в целом, тем меньше время отклика.Zigzug писал(а): Может кластер? Но про это я мало что знаю, точнее сказать вообще ничего не знаю.
Хотя можно подумать и над вариантами: MSSQL умеет работать в кластере. Насколько эффективно ? Не знаю, не пробовал.
Правильно ассоциируется . Если взять "из пальца" и при условии, что все лицензионное - может потянуть что-то около 150-200 т. баксов. Если Вас такой порядок цен устроит - то можно продолжить обсуждение. Нет - тогда смотрите все-таки в сторону х86 . Дешевых RISC-серверов, способных потянуть такую задачу, имхо, нет.А можно подробнее? Какое железо, какой софт, может примерные цены, поставщики? Если это оффтопик, то можно на мыло...
Слово Sun, как и слово Cisco у меня ассоциируется с боооольшими деньгами....
Хм. Конфигурации сервера для сбора информации и аналитического должны бы довольно-таки серьезно отличаться: если для первого характерны чтение и запись "вразброс", то для второго - массированное, практически последовательное чтение - запись значительно реже. Т.е.- как минимум - для первого важнее объем дисковой подсистемы и ОЗУ, для второго - прозводительность дисковой и процессорная мощь.Есть два сервера - Т и К (конфигурация примерно такая-же). На первом происходит сбор информации, а на втором как раз OLAP, поиск по базе и т.д.
Типичная задача OLTP, только - толстая (по моим скромным региональным понятиям, ессно).А задача этой БД - сбор, учет, хранение информации по клиентам. В качестве клиентов выступают частные лица. Соответственно по каждому клиенту нужно иметь информацию по его адресу, что, когда и в каком количестве он купил, когда и как доставили заказ, когда и как оплатил или не оплатил - в общем, масса информации.
Нуу... Хозяин - баринСпецифика работы нашей конторы не позволяет использовать уже что-то готовое. Идея чучхе
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Так.
Если не решитесь менять идеологию , то:
- 8 процессорная платформа и Datacenter - иначе через годик придется вернуться к данной проблеме.
Как сделать (имхо):
- для начала, возьмите 8-процессорную платформу (именно - под сбор данных) с 4-мя установленными процессорами, 12 Гб ОЗУ (с возможностью расширения до 24), пару hot-swap HDD небольшой емкости под систему, производительный внешний RAID с 5 HDD (емкость каждого должна быть не менее размера базы, умноженного на 1,5 - т.е. в Вашем случае, 36 Гб) - делаем RAID10+1 HDD в hot-spare.
- устанавливаем, настраиваем,запускаем: первую неделю - ничего не меняем (!), только, при помощи всех доступных инструментов, ищем узкие места
-в конце первой недели делаем все, что можно решить программно (на основании накопленных и проанализированных данных - тюнинг ОС и SQL-сервера).
- еще неделю - смотрим: есть ли еще проблемы с производительностью. Опять ничего в течение недели не меняем. Убеждаемся во всех предположениях об узких местах на железе.
- в конце недели: добиваем железо, исходя из накопленных данных, с запасом по объему и производительности. Еще неделю - смотрим.
- в конце недели - выполняем окончательный тюнинг всего. После этого можно считать задачу выполненной.
Естественно, весь процесс пуска (особенно - тюнинг и подбор железа) лучше проводить с помощью специалистов фирмы-поставщика сервера. Собранные вами данные об узких местах иногда для Вас могут значить одно, для спеца по данному конкретному железу - другое.
Затем - по аналитическому серверу - процесс тот же.
Если нужны доп. соображения, детали - пишите. Чем можем, как говорится...
Если не решитесь менять идеологию , то:
- 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
- Откуда: Москва
- Контактная информация:
НеаВТБ! писал(а): Аналитика замечательно параллелится, если запрос не один
А с транзакциями как раз всё хуже...
OLAP можно разбить на столько взаимонезависимых нитей, сколько есть запросов, не зависящих от результатов других запросов ( а вот это как раз - дело, имхо, достаточно редкое)...
С транзакциями проще - на каждое клиентское подключение создается поток или нить (зависит от конкретного SQL- сервера). Да если еще учесть, что пользовательские транзакции не слишком активны (нагрузка возникает фактически только при select/fetch или commit/rollback)...Самое дело - для HyperThreading'а.
Последний раз редактировалось a_shats 26 ноя 2002, 14:57, всего редактировалось 1 раз.
Вот это меня и смущает. Сколько будет стоить такой сервак? Ну а с нашими запросами этого на год и хватит.... А дальше что?для начала, возьмите 8-процессорную платформу (именно - под сбор данных) с 4-мя установленными процессорами, 12 Гб ОЗУ (с возможностью расширения до 24), пару hot-swap HDD небольшой емкости под систему, производительный внешний RAID с 5 HDD (емкость каждого должна быть не менее размера базы, умноженного на 1,5 - т.е. в Вашем случае, 36 Гб) - делаем RAID10+1 HDD в hot-spare.
Может сразу эти деньги вложить в sun?
Вопрос даже вот так можно поставить - а какие высокопроизводительные платформы под нашу задачу реально доступны в Москве?
И кто что посоветует?
Я имел ввиду независимые запросы по статичной базе.a_shats писал(а): OLAP можно разбить на столько взаимонезависимых нитей, сколько есть запросов, не зависящих от результатов других запросов ( а вот это как раз - дело, имхо, достаточно редкое)...
Речь шла о параллелизме между узлами кластера.a_shats писал(а):С транзакциями проще...
Самое дело - для HyperThreading'а.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Может. Но - осторожно: никто не гарантирует Вам, что стартовой (той в которой Вам поставят) конфигурации Сановского сервера хватит под Вашу базу на всю оставшуюся жизнь. С одной стороны, Саны масштабируются лучше, чем x86. С другой - недешево это. Порядок цен я назвал.Zigzug писал(а): Может сразу эти деньги вложить в sun?
Подробнее по серверам Sun можно посмотреть здесь:http://www.ixbt.com/cpu/sun-solutions.shtml
А х86 будет сильно дешевле
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя