Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
04.01.2013, 16:18
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Доброго дня. Есть ли какая-то информация для более-менее осмысленного выбора между процессорами от Intel и от AMD. Планируемое использование: - Windows Server 2003 R2 SP2 - MS SQL 2005 Std SP4 - база для 1Сv7 около 20 Гб На данный момент SQL стоит на сервере с двумя Xeon E5540 (2,5 Ghz,4-core), с выключенным HT, 32 Gb RAM, 4хSAS10k RAID10 и прямо сейчас мы упираемся в производительность процессора (график загрузки того же диспетчера задач в винде - постоянно в 100%). при этом остальное железо (судя по Perfomance log) нагружено не так чтоб уж очень сильно, ну память выедается вся - это да, свободной почти нет. Хотим малость апгрейднуть сервер под SQL, и вот мучаемся муками выбора: Intel vs AMD. С одной стороны у AMD сильно больше "честных" ядер (например можно не очень дорого взять HP DL 385 с двумя 16-ядерными Opteron на 2,3 Ghz, а это честных 32 ядра! мама дорогая...) С другой стороны у Intel выше частота и есть HT (Hyperthreading)(например у тех же HP DL380 есть двухпроцессорные модели на Xeon E5-2690 8-core и 2,9 Ghz). HT правда сама MS рекомендует отключать на загруженных системах, но рекомендация уже старая довольно, и есть интернет-энтузиасты, которые говорят, что в новых моделях процессоров с HT все сильно лучше, мол все оптимизировано и считай что на халяву в 2 раза больше ядер получаешь, включать надо однозначно) Что посоветуете, уважаемые знатоки? Где можно посмотреть адекватные тесты на более-менее современных процессорах? Как вообще можно выбрать в этой ситуации, какие шаги предпринять, чтобы потом не было мучительно больно... Про остальные части сервера мы не забыли, и будем брать их с запасом, чтоб точно исключить из списка "бутылочных горлышек", будут 2 SSD в RAID1 на приличном RAID контроллере от HP с минимум 1Gb кешем, будет не менее 64 Гб Reg Ecc памяти (кроме основной базы будет и несколько других сильно менее важных, но тем не менее больших по объему) и т.д. Саму БД, ее архитектуру, оптимизировать к сожалению пока никак нельзя(я даже не касаюсь уродских вывертов 1Сv7 при работе с SQL которые там есть от рождения) - работы над этим ведутся параллельно, но закончатся дай бог в этом году ближе к концу - а работать надо уже сейчас. Поэтому получено добро на новый сервер - и вот.. в ожидании денег - мучаемся с выбором. Поможете советом? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 16:32
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
acherepovНа данный момент SQL стоит на сервере с двумя Xeon E5540 (2,5 Ghz,4-core), с выключенным HT, 32 Gb RAM, 4хSAS10k RAID10 и прямо сейчас мы упираемся в производительность процессора (график загрузки того же диспетчера задач в винде - постоянно в 100%). при этом остальное железо (судя по Perfomance log) нагружено не так чтоб уж очень сильно, ну память выедается вся - это да, свободной почти нет. Вот и покажите графики. acherepovПро остальные части сервера мы не забыли, и будем брать их с запасом, чтоб точно исключить из списка "бутылочных горлышек", будут 2 SSD в RAID1 на приличном RAID контроллере от HP с минимум 1Gb кешем, будет не менее 64 Гб Reg Ecc памяти (кроме основной базы будет и несколько других сильно менее важных, но тем не менее больших по объему) и т.д. Может, отдельные базы стоит вынести отдельно? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 17:25
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
acherepovНа данный момент SQL стоит на сервере с двумя Xeon E5540 (2,5 Ghz,4-core), с выключенным HT, 32 Gb RAM, 4хSAS10k RAID10 и прямо сейчас мы упираемся в производительность процессора (график загрузки того же диспетчера задач в винде - постоянно в 100%). при этом остальное железо (судя по Perfomance log) нагружено не так чтоб уж очень сильно, ну память выедается вся - это да, свободной почти нет. Есть у меня такое подозрение, что процессор утилизируется на 100% не потому, что ему там мощности не хватает, а по каким-либо другим причинам. Восемь зеоновых ядер - это вполне достаточно, чтобы обрабатывать данные с той скоростью, с которой их способен выдавать четырехвинтовый рейд. Начните с того, что смотреть нужно не в диспетчер задач винды, а хотя бы в панель мониторинга SQL-сервера. Там показываются ресурсы, которые реально потребляет сервер, и указано, для каких запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 17:26
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Я бы выбрал на интеловых зеонах - удачная линейка - высокая производительность многопроцессорных систем на которых Интел собаку уже съел, греются не сильно. а амдшники сами признают, что не сильные игроки в этом сегменте. тут разве что вопрос цены.. А по поводу НТ - давно уже все допилено и нормально работает, в первых релизах НТ были косяки, и его отключали - сейчас все на ура, пробовали отключать для СУБД тяжелой - результаты хуже гораздо. И к тому же, у интела сейчас процов, ну всяких разных, сколько надо физ ядер можно накопать 9в разумных пределах конечно) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 17:32
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
авторЕсть у меня такое подозрение, что процессор утилизируется на 100% не потому, что ему там мощности не хватает, а по каким-либо другим причинам. Восемь зеоновых ядер - это вполне достаточно, чтобы обрабатывать данные с той скоростью, с которой их способен выдавать четырехвинтовый рейд. Если у них сожрана вся память, то база наверняка в оперативке крутится и к винтам обращается не часто, но согласен, что старый таск менеджер 2003 винды не самый точный показатель) З.Ы У одного клиента просто поменяли старые интелы на новые (смена только одного поколения) - проведение обработки по времени упало в 3 раза, при том, что новые интелы были вполне бюджетные и не самые новые, а если новые зеоны е5 воткнуть, там вообще ураган был бы) Но тут уж как придется, кто-то код оптимизирует. а кому проще железо новое воткнуть. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 19:30
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
acherepovпрямо сейчас мы упираемся в производительность процессора (график загрузки того же диспетчера задач в винде - постоянно в 100%).Это точно от сиквела? Может, это приложение 1С грузит? И если от сиквела, то желательно понять, из за чего грузит. Вроде 1С больше требовательна к дискам. Может, это какой то самодельный кривой отчётный (или ещё какой то) запрос, и его легко поправить? По теме - всегда предпочитал Intel ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.01.2013, 23:45
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Обратитесь в профильный (1С) форум. Из личной практики: в SQL отключите одно ядро и переключите на него серверный процесс 1С; ограничите память для SQL. И голосую за Intel. Таки MS точит свои программы под них. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.01.2013, 17:22
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.01.2013, 17:37
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Константин ЦветковОбратитесь в профильный (1С) форум. Из личной практики: в SQL отключите одно ядро и переключите на него серверный процесс 1С; ограничите память для SQL. И голосую за Intel. Таки MS точит свои программы под них. а вообще у нас сейчас тренд такой : безграмотные алгоритмы заливать быстрым железом 100% sql запросы работатают без использования индексов , программёры про индексы не знают или обновление статистики выключено ... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.01.2013, 20:56
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
aist-psk100% sql запросы работатают без использования индексов , программёры про индексы не знают 0% (1С — явно не ваш профиль). В 1С в запросы явно прописаны индексы, которые периодически перестраиваются. Но псевдо-ООП не способствует построению хороших планов запроса. И многопоточность для 1С — большая проблема. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
07.01.2013, 22:26
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Константин Цветковaist-psk100% sql запросы работатают без использования индексов , программёры про индексы не знают 0% (1С — явно не ваш профиль). В 1С в запросы явно прописаны индексы, которые периодически перестраиваются. Но псевдо-ООП не способствует построению хороших планов запроса. И многопоточность для 1С — большая проблема. Неплохо бы уточнить, клиенты 1С вертятся также на этом сервере, или сервер несет на себе только MS SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.01.2013, 13:12
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
ДжекНепотрошительКонстантин Цветковпропущено... 0% (1С — явно не ваш профиль). В 1С в запросы явно прописаны индексы, которые периодически перестраиваются. Но псевдо-ООП не способствует построению хороших планов запроса. И многопоточность для 1С — большая проблема. Неплохо бы уточнить, клиенты 1С вертятся также на этом сервере, или сервер несет на себе только MS SQL. 1С — клиент-сервер. Клиент (толстый или тонкий — автомат включает в зависимости от скорости канала) работает с серверным сервисом 1С, который (судя по вводным) находится на одном сервере с SQL. Терминальный доступ они (судя по...) не используют. Этот 1С-сервис (rphost.exe) постоянно борется с SQL за память, а SQL забирает себе всё что сможет, в надежде построить хороший план, но запросы 1С настолько перегружены всякой ... от ООП, что SQL фактически ничего не может (работает просто как транзакционный доступ к данным). Ставил эксперимент: вместо 1С-запроса (на русском "ВЫБРАТЬ"...) ставил простой ADO-коннект запрос — скорость увеличивалась на порядок. Кстати, есть фирмы, которые переписывают 1С на ADO, после чего отпадает вопрос acherepov -а. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.01.2013, 19:07
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
ну так и выходит : от переизбытка интеллекта в запросах 1C - оптимизатор СУБД просто опускает руки . лечить это невозможно , только через отрубание головы (1С) вот за что люблю 1Сэшнков , так это за волю к жизни и ОПТИМИЗМ ! ... |
|||
:
Нравится:
Не нравится:
|
|||
|
08.01.2013, 22:11
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
32 Gb RAM и база 20 гб !!! и всё тормозит !!! вот он маразм автоматизации. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 10:45
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Обожаю профессиональные сообщества! :) По существу: - нет, отдельные базы отдельно вынести не получится. Нюансы внутренней политики. Соответственно на данном этапе мы скорее добавим еще оперативки на новом сервере, благо она дешевая, чем будем махать шашкой и перекраивать внутренние регламенты компании. - 100% загрузки процессора, это моя вина, некорректно выразился. Прошу прощения. У нас терминал и SQL расположены на одном сервере, и 100% загрузка получается при одновременной работе более чем 150 пользователей(это не пик нагрузки, это планка, выше которой начинаются тормоза, пик нагрузки - это человек 200 наверное, больше не пробовали) или в отчетный период, когда одновременно считается большое количество различных отчетов. Доля самого SQL при 100% загрузке процессора достигает 40-50%. В данном случае речь идет все еще про диспетчер задач (я понимаю его несовершенство, но как некая линейка, от которой можно хотя бы начать отталкиваться - он вполне ок). По остальным советам, даже не знаю что сказать. На всякий случай кратко повторю вводную: 1. У нас есть: 1Сv7(сильно переписана и изменена) + терминальный сервер + SQL 2005. Это базис, аксиома. Эти условия к сожалению не изменить в ближайшие год-полтора. Работа над этим ведется, но процесс будет очень небыстрым. 2. Мы хотим вынести SQL на отдельный сервер, распределив таким образом нагрузку (хотя тут еще бабушка надвое сказала во всех ли ситуациях система будет работать быстрее). 3. Для нового сервера есть возможность (цена конечно важна, но если НУЖНО от деньги не будут проблемой) взять железо максимально (!) удовлетворяющее всем его потребностям (планируемая нагрузка - только SQL 2005) Собственно вопрос то был: какие процессоры более подходящи для SQL 2005 (если версия SQL в данном случае важна)? Есть ли разница между AMD и Intel в этом отношении, при прочих равных (исключая цену)? Можно ли где то посмотреть обзоры\сравнения (если их проводят таким образом) на эту тему? Сам нашел только довольно древний обзор на AnandTech, по которому в общем не очень понятно что и как. С одной стороны Intel мощнее процентов на 15, но с другой при 40% разнице в тактовых частотах - ожидаешь сопоставимую разницу в производительности ,а не в 3 раза меньшую. В нынешних процессорах разница в тактовой частоте не более 25%, что наводит на всякие сомнения относительно прироста производительности. Опять же число честных ядер(про НТ пока умолчим), у AMD сейчас сильно больше чем у intel (16 против 8), что тоже повод для раздумий, даже если сравнивать косвенно по ценовой политике MS :) (мы лицензии покупать не будем, если что, они уже есть на 2005 версию, а там, как известно лицензируется на процессор а не на ядра, так что этот бич нас слава богу миновал, иначе боюсь даже подумать сколько стоил бы сам SQL скажем на сервере с двумя 16-Core Opteron) Вот и спросил, думал речь пойдет про особенности архитектуры процессоров, какие-то балалайки из личного опыта, небольшой холивар на тему Intel vs AMD, а оно вона как обернулось. Ну ок. Спасибо всем за советы. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 11:08
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
Возьмите железо в тест - свистните интеграторов, сами прибегут и притащат все, недели на три точно можно взять (сервера+схд), вот и посмотрите. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 11:32
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
acherepov- 100% загрузки процессора, это моя вина, некорректно выразился. Прошу прощения. У нас терминал и SQL расположены на одном сервере, и 100% загрузка получается при одновременной работе более чем 150 пользователей(это не пик нагрузки, это планка, выше которой начинаются тормоза, пик нагрузки - это человек 200 наверное, больше не пробовали) или в отчетный период, когда одновременно считается большое количество различных отчетов. Ну вот это больше похоже на правду. Мой совет такой: купите отдельный сервер с большим количеством мозгов (процессор роли не играет) под терминалку, а существующий отдайте целиком под SQL. Существующего вам еще на несколько лет хватит, чесслово. Учитывая, что 32Гб памяти достаточно, чтобы вашу базу закешировать по самые помидоры. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 12:11
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
rahzerВозьмите железо в тест - свистните интеграторов, сами прибегут и притащат все, недели на три точно можно взять (сервера+схд), вот и посмотрите. Проблема в том, что не очень ясно чем и как тестировать. Переводить всю работающую систему на новый сервер - процесс очень небыстрый (там не закуклено все на одном сервере, там есть несколько взаимосвязанных компонентов, их перенастройка тоже нужна, плюс неизбежные глюки и проблемы переезда, и учитывая что все это временное, "чтобы попробовать" - не, думаю не решимся) , да и не получим мы нашу пороговую нагрузку сразу, должно пройти некоторое время (~неделя) чтобы нагрузка добралась до этого порога. Гонять синтетические тесты - какие? Посоветуете что-нибудь? Я думал мнение сообщества услышать, по нему уже как-то сориентироваться. Может кто-то уже гонял синтетику на разном железе (тестировщики, оверклокеры, ит-энтузиасты ау, где вы?) - его мнение тоже очень бы пригодилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 12:15
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
ДжекНепотрошительНу вот это больше похоже на правду. Мой совет такой: купите отдельный сервер с большим количеством мозгов (процессор роли не играет) под терминалку, а существующий отдайте целиком под SQL. Существующего вам еще на несколько лет хватит, чесслово. Учитывая, что 32Гб памяти достаточно, чтобы вашу базу закешировать по самые помидоры. Я правильно вас понял, что двух процессоров Xeon с 4 ядрами хватит очень надолго, при условии использования только под SQL? т.е. нет смысла увеличивать число ядер, выбирать архитектуру и все вот это, достаточно только обеспечить нужное количество оперативной памяти? У нас ведь там есть еще несколько баз (конечно гораздо, гораздо меньших по вычислительной нагрузке, но сопоставимых по объему) даже с учетом них не стоит обновлять железо? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 14:39
|
|||
---|---|---|---|
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
авторГонять синтетические тесты - какие? Синтетика - это синтетика, она не даст особо осязаемых результатов..Ну будете знать, что вот эти процессора быстрее вон тех на определенное количество попугаев (попугаи зависит от тех тестов, которыми гонять будете - латентность кэша, арифметика и прочее) и какое это представление как это будет в 1С работать, насколько быстрее? По дисковой подсистеме, там да, там синтетика типа iometer или sqlio+мониторинг производительности. Оперативка - ну она по количеству, хотя скуль все сжирает, сколько не дай) По терминальным сессиям проще, понять и ограничить. Под 1С8 есть инструменты 1С, которые позволяют сымитировать одновременную работу пользователей.., ну и еще там всякую фигню. Под 1С7 - х.з На предыдущем поколении Xeon (e5606) синтетика 1С-ная показывала до 450 пользователей. Было 2 сервака IBM M3 2*XeonE5606,48GB RAM 1066Mhz, дисковая подсистема IBM3512 (1GB cache).8*HDD 15K rpm На одном стоял сткуль, на втором терминалка. Но самый лучший тест - это тест реальной базы, мы тестили УПП 8 версии, база 60 гигов. На старой 4-х сокетной платформе с 6-ядерными процами обработки шли по часу и в базе работать никто не мог, на тестовой платформе время сократилось в 3 раза+в базе народ мог работать. Это при том, что серваки дохлые и старого поколения и схд не самая производительная. Да и 1с7 - она же со скулем работает неоптимально, старая платформа, там она тупо в свои ограничения утыкается, чем в железо. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
09.01.2013, 15:29
|
|||
---|---|---|---|
|
|||
Intel vs AMD для MS SQL 2005. Извечный вопрос. |
|||
#18+
rahzerСинтетика - это синтетика, она не даст особо осязаемых результатов..Ну будете знать, что вот эти процессора быстрее вон тех на определенное количество попугаев (попугаи зависит от тех тестов, которыми гонять будете - латентность кэша, арифметика и прочее) и какое это представление как это будет в 1С работать, насколько быстрее? По дисковой подсистеме, там да, там синтетика типа iometer или sqlio+мониторинг производительности. Оперативка - ну она по количеству, хотя скуль все сжирает, сколько не дай) По терминальным сессиям проще, понять и ограничить. Под 1С8 есть инструменты 1С, которые позволяют сымитировать одновременную работу пользователей.., ну и еще там всякую фигню. Под 1С7 - х.з На предыдущем поколении Xeon (e5606) синтетика 1С-ная показывала до 450 пользователей. Было 2 сервака IBM M3 2*XeonE5606,48GB RAM 1066Mhz, дисковая подсистема IBM3512 (1GB cache).8*HDD 15K rpm На одном стоял сткуль, на втором терминалка. Но самый лучший тест - это тест реальной базы, мы тестили УПП 8 версии, база 60 гигов. На старой 4-х сокетной платформе с 6-ядерными процами обработки шли по часу и в базе работать никто не мог, на тестовой платформе время сократилось в 3 раза+в базе народ мог работать. Это при том, что серваки дохлые и старого поколения и схд не самая производительная. Да и 1с7 - она же со скулем работает неоптимально, старая платформа, там она тупо в свои ограничения утыкается, чем в железо. Спасибо. Именно то, чего хотелось. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=30&mobile=1&tid=1529925]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 174ms |
0 / 0 |