Intel Itanium 2 vs AMD Opteron, 4CPU
Модераторы: Trinity admin`s, Free-lance moderator`s
Intel Itanium 2 vs AMD Opteron, 4CPU
Привет Всем!
Подскажите по опыту. Что быстрее, что предпочесть, на чем остановить свой выбор?
Может быть есть ссылки на benchmark'и?
Подскажите по опыту. Что быстрее, что предпочесть, на чем остановить свой выбор?
Может быть есть ссылки на benchmark'и?
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Бенчмарки - на http://spec.org
Главный вопрос - а для чего ? Для каждой задачи - свое решение.
Опишите - для чего Вам такое нужно - посоветуем что-нибудь по-конкретнее.
Главный вопрос - а для чего ? Для каждой задачи - свое решение.
Опишите - для чего Вам такое нужно - посоветуем что-нибудь по-конкретнее.
Спасибо, посмотрел, кстати сайт правильно www.spec.org
до конца правдо не понял, как провести аналогии или найти нужное мне.
Еще много спеков нарыл на www.amd.com , но как то боязно их клонировать под нашу задачу.
Задача: MS, Axapta, SQL сервер, 350 пользователей сейчас, планируется до 600. База размером 100GB. Индексный файл 5-7GB.
Но проблема не в хранилище - здесь я вроде склонился к Hitachi ( мож правда еще кто чего предложит ) , а именно в сервере.
Для нас отчеты за минимальное время - самое главное.
Начальство похоже настроенно именно на Itanium :?
до конца правдо не понял, как провести аналогии или найти нужное мне.
Еще много спеков нарыл на www.amd.com , но как то боязно их клонировать под нашу задачу.
Задача: MS, Axapta, SQL сервер, 350 пользователей сейчас, планируется до 600. База размером 100GB. Индексный файл 5-7GB.
Но проблема не в хранилище - здесь я вроде склонился к Hitachi ( мож правда еще кто чего предложит ) , а именно в сервере.
Для нас отчеты за минимальное время - самое главное.
Начальство похоже настроенно именно на Itanium :?
-
- Advanced member
- Сообщения: 81
- Зарегистрирован: 16 фев 2004, 22:49
- Откуда: Moscow
- Контактная информация:
В Вашем случае ключевое слово - MSSQL. При Ваших объемах памяти портебуется немеряно. 64-битных редакций для Amd64 у сиквела нет, есть AWE, но это не то чтобы совсем беспроблемный вариант. Т.е. Вам прямая дорога на Itanium 2 (само собой, imho)Nikel писал(а):Задача: MS, Axapta, SQL сервер, 350 пользователей сейчас, планируется до 600. База размером 100GB. Индексный файл 5-7GB
P.S. success story на похожей задаче. Я в ней не клиент и не поставщик, ничего не покупаю и не продаю. По многим пунктам готов спорить, но сама по себе машина внушает уважение, было немного времени кнопки в ней понажимать Там система конечно с большим запасом покупалась, но юзеров раза в два меньше, чем сейчас у Вас
P.P.S. Не совсем понятно (вернее, совсем непонятно) о каком индексном файле речь - это transaction log?
P.P.P.S. Очень интересные у Вас задачи и объемы данных. Если что, можно будет вопросы позадавать?
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Трижды хм. Насчет Итаниума. Дело в том, что 32-битный софт давным-давно отлажен, и по крайней мере все основные грабли известны. Тот же самый AWE не такое уж и суровое пугало - снижение производительности от AWE и PAE не так уж и велико. Но - на самом деле, это все не так уж и важно - какая именно будет платформа одного сервера, куда важнее - соорудить решение всей задачи в целом.
Что касается Вашей задачи - ключевые слова MSSQL и масштабируемость. Сейчас Вам необходимо создать решение так, чтобы впоследствии его производительность достаточно легко наращивалась. Это я все к тому, что MSSQL сервер у Вас должен быть более, чем один - изначально и заложена возможность добавления серверов. Тем более, что Axapta изначально трехзвенная (клиент-сервер приложения - сервер SQL), стало быть серверов в любом случае будет больше одного. Иначе - через годик придете к тому, от чего сейчас пытаетесь уйти.
Грабли тут в том, что решения, подобного Oracle RAC (Real Applications Cluster) для MSSQL нет, и персонально мне неизвестно, будет ли.
Вот и вопрос: собираетесь Вы оставить в итоге один SQL-сервер или же все же предусмотреть возможность масштабирования ?
Что касается Вашей задачи - ключевые слова MSSQL и масштабируемость. Сейчас Вам необходимо создать решение так, чтобы впоследствии его производительность достаточно легко наращивалась. Это я все к тому, что MSSQL сервер у Вас должен быть более, чем один - изначально и заложена возможность добавления серверов. Тем более, что Axapta изначально трехзвенная (клиент-сервер приложения - сервер SQL), стало быть серверов в любом случае будет больше одного. Иначе - через годик придете к тому, от чего сейчас пытаетесь уйти.
Грабли тут в том, что решения, подобного Oracle RAC (Real Applications Cluster) для MSSQL нет, и персонально мне неизвестно, будет ли.
Вот и вопрос: собираетесь Вы оставить в итоге один SQL-сервер или же все же предусмотреть возможность масштабирования ?
-
- Advanced member
- Сообщения: 81
- Зарегистрирован: 16 фев 2004, 22:49
- Откуда: Moscow
- Контактная информация:
Согласитесь, это не значит, что 64-битные (конкретно Windows и MSSQL) - глюкало Человек же перед тем, как покупать, вытребовал себе этот сервер на тестирование - работает ВСЕ и РОВНО ТАК ЖЕ, как на 32. Разница только в производительностиa_shats писал(а):Трижды хм. Насчет Итаниума. Дело в том, что 32-битный софт давным-давно отлажен, и по крайней мере все основные грабли известны.
Бог с ней, с производительностью - а вот как раз проблемы с AWE возникают почаще, чем без негоa_shats писал(а):Тот же самый AWE не такое уж и суровое пугало - снижение производительности от AWE и PAE не так уж и велико.
Плюс некоторые различия "внутре" - например, в 32-бит ограничено 2 Гб количество памяти, выделяемой под скомпилированные планы исполнения и блокировки, во что это выливается для OLTP, думаю, понятно. 64-bit Edition этим не страдает
Решение есть - см. Federated Database Servers, вот только это подразумевает изменения в структуре БД, которые Аксапта переносит, мягко говоря, не очень хорошоa_shats писал(а):Грабли тут в том, что решения, подобного Oracle RAC (Real Applications Cluster) для MSSQL нет, и персонально мне неизвестно, будет ли.
Про RAC очень правильные слова, отличная технология
Но в постановке задачи фигурировал MSSQL
Повторюсь: я железом не торгую, я смотрю на 64-бит решения как разработчик / dba - мне очень нравится. Вот только бы прайс на них сделать немного погуманнее, и будет микрокоммунизм
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Да, не значит. Я же сказал - это не имеет значения Платформа выбирается только в контексте готового решения, по принципу - что именно лучше подходит. Можно и на Ксеонах решение выстроить А не - смотреть на платформу - а потом подбирать решение под нее.
Вот на 4-way (а теперь и 8-Way) Оптероны - как раз прайсы весьма гуманные. В сравнении с.
Вот на 4-way (а теперь и 8-Way) Оптероны - как раз прайсы весьма гуманные. В сравнении с.
-
- Advanced member
- Сообщения: 81
- Зарегистрирован: 16 фев 2004, 22:49
- Откуда: Moscow
- Контактная информация:
Мой ход мысли таков: если бюджет позволяет "нативно" использовать большие объемы памяти для сервера СУБД (а он не может не позволять - шутка ли, полтыщи лицензий на аксапту), надо его осваивать
Замечательные слова про платформы и решения. Вот только к решению на AWE я отношусь немного настороженно и, если бюджет позволяет, выбрал бы другое
Вы уже готовы предлагать решения на 4-way оптеронах? Можете навскидку посчитать конфигурацию без дисковой системы?
Замечательные слова про платформы и решения. Вот только к решению на AWE я отношусь немного настороженно и, если бюджет позволяет, выбрал бы другое
Вы уже готовы предлагать решения на 4-way оптеронах? Можете навскидку посчитать конфигурацию без дисковой системы?
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 22 гостя