Jump to content
Калькуляторы

WEB Server on Opteron.

Собственно , интересно мнение людей эксплуатирующих такое (на современных 6x оптеронах). По цене и количеству ядер оно с виду интереснее Интела , но возникает много вопросов (последние лет 7 использовал только xeon'ы).

 

1. Доставаемость (RU,MSK) 1U платформ. Очень редко встречал предложения , у supermicro их мало , Tyan не особо возят. Может есть что проверенное приличное?

2. Производительность. Вероятно выше xeon'ов той же ценовой категории (ядер больше , но у xeon еще и HT), но тестов не нагуглил с нагрузкой характерной для web сервера.

 

P.S. В 4 квартале AMD обещает начать поставки A1100 (ARM) , вот такое было бы интересно заполучить , в случае приличной производительности...

Share this post


Link to post
Share on other sites

П1. все убивает. По энергопотреблению тоже менее эффективно AFAIK.

Люди из STSS мне говорили что для достижения равной производительности цена Xeon и AMD все равно будет практически одинаковой.

Share this post


Link to post
Share on other sites

оптерон не торт, зеон торт

не пользовались --- и не пользуйтесь, производительность amd`шных поделок при тех же частотоах что и у интела вообще никакая, имеет смысл их пользовать только при заранее никакой загрузке и посещаемости если надо скроить, но такое кроилово может рано или поздно аукнуться попадаловом

амд просерает что с десктопными, что с серверными процами, и при тойже производительности что и у интела, надо покупать более старшие модели у амд. ну и в завершение --- производительность северных и южных мостов для амдшных поделок гораздо хуже чем у интела.

 

короче вывод простой: если надо выбрать проц для сервера то выбирать в 86 архитектуре можно только из интела и ...интела, если на архитектуру пофигу то выбирать из интела и ibm power7 с жирным перевесом на power7, amd тут и рядом невалялось с ними обоими

Share this post


Link to post
Share on other sites

На архитектуру пофиг. В общем понятно с amd. Power может и интересен , но вроде нет в природе 1U серверов на них.

Share this post


Link to post
Share on other sites

Да какбы amd вполне неплохи, если для веб-сервера. Возможно, 32 ядра (16 модулей) пайлдрайвера будет сопоставимо со скоростью с 12-16 ядрами зиона на равной частоте, а может - и побыстрее будет... Ядра модуля как-никак практически независимы (общий FPU не в счет, общий декодер команд тоже несколько снижает пиковую производительность - но не особо значительно). Ну и да, местами много слабых ядер предпочтительнее малого кол-ва мощных.

 

Главная проблема - локальная доступность.

Share this post


Link to post
Share on other sites

По какому параметру оптимизируем задачу?

По числу вычислительной мощи на сервер или же по плотности на юнит?

А может по теплу на юнит?

 

Когда искал решение для большого количества распределенной вычислительной мощи, попалось занятное решение на атомах HP Moonshot.

По теплу и мощности в стойку в 10КВт можно запихнуть заметно больше мощи, если она не должна быть в одном месте, на одном сервере.

 

Правда до реализации решение пока не дошло, поэтому и реальным опытом не поделюсь.

 

Там и AMD версии есть, кстати :).

Share this post


Link to post
Share on other sites

(общий FPU не в счет, общий декодер команд тоже несколько снижает пиковую производительность - но не особо значительно)

Так же в расчет не будем брать общий L2-кэш на пару ядер и один контроллер памяти?

Share this post


Link to post
Share on other sites

Вот в схемотехнике амд и проигрывает, от того и тормоза, по началу они мегагерцами выезжать пытались, а как только уперлись в потолок по частотам так и перестали хоть как то опережать интел, к схемотехнику развивать несколько соложнее чем мегагерцы гнать

Share this post


Link to post
Share on other sites

Так же в расчет не будем брать общий L2-кэш на пару ядер и один контроллер памяти?

Общий л2-кеш может быть не только минусом, но и плюсом. Контроллер памяти - он в любом случае общий. Только у G34 сокета внутри - 2 контроллера памяти и 2 кристалла, а у интела - один сокет - один контроллер памяти, один л3 кеш.

 

Ну и да, я модуль сравнивал с одним ядром с гипертрейдингом. Так вот, для 2 целочисленных потоков модуль амд будет предпочтительнее ядра интела со вторым виртуальным потоком.

Share this post


Link to post
Share on other sites

Раз уж пошло обсуждение - может кто все-же видел тесты (сам тестил) x vs o на характерной для web сервера нагрузке:

mysql , php(с популярными cms) , отдача по http файла в много потоков и.т.д.

Share this post


Link to post
Share on other sites

Общий л2-кеш может быть не только минусом, но и плюсом. Контроллер памяти - он в любом случае общий. Только у G34 сокета внутри - 2 контроллера памяти и 2 кристалла, а у интела - один сокет - один контроллер памяти, один л3 кеш.

 

Вполне может быть, но это не тот случай. Чтобы использовать преимущества шаред-кэша надо делать это явно. А сейчас ни ОС ни апач о кэше цпу не думают.

 

Не нашел подтверждений что на G34 2 контроллера, про Interlagos написано лишь 4-канала, да и это не удивительно.

 

ПС. Где-то была замечательная исследовательская работа отечественного авторства, в которой прекрасно раскладывались проблемы общих кэшей и общей памяти многоядерных SMP-систем. Дык вот, всем адептам мнения "многоядер это круто" её надо читать до просветления 2-3-4 раза :)

Share this post


Link to post
Share on other sites

Блейды штоле?

Не-е. Блейды - это 8-16 серверов на Xeon-ах в 10-12U.

Это - 45 hot-pluggable серверов на Atom-ах (есть оптероны, но там плюс встроенная графика для специфических задач) в 4,3U.

 

Atom-ы заметно эффективнее по тепловыделению по сравнению с Xeon-ми, но сильно менее мощные. Если у вас десятки (и более) серверов на Xeon-ах выполняют тысячи однотипных задач, то можно их заменить на сотни атомов, которые будут делать тоже самое суммарно эффективнее.

Share this post


Link to post
Share on other sites

Вполне может быть, но это не тот случай. Чтобы использовать преимущества шаред-кэша надо делать это явно. А сейчас ни ОС ни апач о кэше цпу не думают.

В любом случае - картина не хуже, чем у одного интеловского ядра с двумя потоками. Там - все ресурсы шарятся. Здесь - раздельные исполнительные устройства.

 

Не нашел подтверждений что на G34 2 контроллера, про Interlagos написано лишь 4-канала, да и это не удивительно.

Внутри банальная склейка из двух обычных кристаллов, соединенных по HT... NUMA, да.

 

Где-то была замечательная исследовательская работа отечественного авторства, в которой прекрасно раскладывались проблемы общих кэшей и общей памяти многоядерных SMP-систем. Дык вот, всем адептам мнения "многоядер это круто" её надо читать до просветления 2-3-4 раза :)

Дык все зависит от того, насколько потоки связаны между собой. Если совершенно не связаны (а веб-сервер - именно такая задача, как и СУБД, каждый поток молотит свои общие данные) - то идеальная производительность будет при кол-ве ядер равном кол-ву запросов, по мере уменьшения кол-ва ядер будут расти накладные расходы на переключение контекста, и наихудший случай - это когда есть одно сверхъядро.

Share this post


Link to post
Share on other sites

Тут про php народ написал, это убийство, оно на любом процессоре тормоз полный, потому что гладиолус, можно спорить как по производительности статический линкарь на сях или сях с плюсами работать будет, или на худой конец Ява, или что то что компилируется. А пхп оно и в Африке больше 10, максимум 20 запросов в секунду не тащит. Потому что пэхапэ... И по секунде или две время генерации страниц такого убожества как umi или по подчеркнула у других, это убийство. Если интересно то возьмите лоад раннер и напишите нормальные тесты и увидите что оно мертво рожденное даже мерзенькая винда на c# веселее из под iis работает чем пхп на любом юниксе и беда не в юниксе...

Share this post


Link to post
Share on other sites

Дык все зависит от того, насколько потоки связаны между собой. Если совершенно не связаны (а веб-сервер - именно такая задача, как и СУБД, каждый поток молотит свои общие данные) - то идеальная производительность будет при кол-ве ядер равном кол-ву запросов, по мере уменьшения кол-ва ядер будут расти накладные расходы на переключение контекста, и наихудший случай - это когда есть одно сверхъядро.

 

 

Любой сетевой пакет в юзерленд - переключение контекста, вымывание кэша, не говоря уж о прерывании.

Не надо больше рассуждать, давайте уже бенчмарки показывайте :)

Share this post


Link to post
Share on other sites

Любой сетевой пакет в юзерленд - переключение контекста, вымывание кэша, не говоря уж о прерывании.

Дык кол-во пакетов будет то же самое что для одого ядра, что для десятка. Только одно но - когда 100500 ядер, пакет пришел на одно ядро при этом остальные ядра не отвлекаются, когда 1 ядро - из-за прерываний и переключений контекста будет активное вымывание кеша...

 

Запустите компиляцию чего-то на 4-головом камне с -j 5 скажем, и с -j 50. В каком случае быстрее соберется? :)

Share this post


Link to post
Share on other sites

Дык кол-во пакетов будет то же самое что для одого ядра, что для десятка. Только одно но - когда 100500 ядер, пакет пришел на одно ядро при этом остальные ядра не отвлекаются, когда 1 ядро - из-за прерываний и переключений контекста будет активное вымывание кеша...

 

Это все и есть тюнинг. Того чего нет в обычной системе, установленной снуля. Т.е. в идеале надо вывалить kernel-context на какое-то одно ядро, user-context на другие. Прибить жестко это все и получить какой-либо положительный результат. Но вот с шаред кэшем все немного сложнее. Процессоры борются за доступ к нему, как и к памяти. Чем больше вычислительных ядер на один домен памяти/кэша тем больше конкуренция за доступ к нему. Это иногда приносит плохие результаты. Поэтому я и говорю о том, что в идеале на один контроллер (строго ИХМО! тут все зависит от вида нагрузки) должно приходиться 4 ядра, и тогда будет любовь-мир-доброта. И конечно же ОСь должна уметь NUMA сполна. NUMA кстати не отменяет конкурентности в области shared-data, которой тоже на самом деле много. А вот доступ одного процессора к памяти другого уже очень затратная операция.

Ни в каких таких наших апачах/нгинксах ничего подобного не учтено. Для них память это память, она просто есть и все.

 

Запустите компиляцию чего-то на 4-головом камне с -j 5 скажем, и с -j 50. В каком случае быстрее соберется? :)

 

Пробовали и не раз :) Все сильно зависит от того дает ли makefile такую возможность, и если дает это тоже не всегда имеет результат. Раньше было развлечением проверять как влияет -jX на сборку world. Дак вот: зависимость не линейна. Условно говоря при кол-ве параллелизма равном кол-ву ядер - результат наилучший. Но он все равно не линеен, от -j2 до -j8 не ускоряется всё в 4 раза, даже в 3 не дает. -j50 при 8 ядрах может дать даже обратный эффект, простои связанные с доступом к диску и памяти могут пересилить выгоду от кучи процессов. Увы и ах. (Кстати прекрасный пример того - наш любимый микротик о 36ядрах, на которые сыпятся интеррапты).

Share this post


Link to post
Share on other sites

Это все и есть тюнинг. Того чего нет в обычной системе, установленной снуля.

Нет, это обычное поведение. Ядра молотят данные, пока одно из них отвлекается на прерывание.

 

Но вот с шаред кэшем все немного сложнее. Процессоры борются за доступ к нему, как и к памяти. Чем больше вычислительных ядер на один домен памяти/кэша тем больше конкуренция за доступ к нему. Это иногда приносит плохие результаты.

Конкурирующие потоки/процессы на одном ядре будут предпочтительнее конкурирующих за доступ к кешу ядер?

 

Поэтому я и говорю о том, что в идеале на один контроллер (строго ИХМО! тут все зависит от вида нагрузки) должно приходиться 4 ядра, и тогда будет любовь-мир-доброта.

У зионов до 12 (или до 10?) ядер на один ИКП - и ничо.

 

Ни в каких таких наших апачах/нгинксах ничего подобного не учтено. Для них память это память, она просто есть и все.

Ессно, память - это просто память. Ибо нет практически взаимодействия между потоками. А один поток прекрасно разбирается со своей памятью, если ему ось помогает.

 

Условно говоря при кол-ве параллелизма равном кол-ву ядер - результат наилучший

Порой - при кол-ве потоков = кол-ву ядер + 1 (пока процесс ждет окнчания i/o, "запасной" процесс работает)

 

-j50 при 8 ядрах может дать даже обратный эффект, простои связанные с доступом к диску и памяти могут пересилить выгоду от кучи процессов.

Не может дать, а обязательно даст. переключение контекста между процессами, вымывание кеша и т.п...

 

Кстати прекрасный пример того - наш любимый микротик о 36ядрах, на которые сыпятся интеррапты

Ну микротик - там роутинг, и в общем случае в роутинге все упирается в латентность памяти (ну или кешей если DMA контроллер юзает кеш), а не в ядра. В качестве веб-сервера он бы показал себя куда интереснее...

Share this post


Link to post
Share on other sites

Нет, это обычное поведение. Ядра молотят данные, пока одно из них отвлекается на прерывание.

 

Ну в теории это так. Но на практике прерывания плавают по ядрам, если вы их руками не перемолотили куда надо. А еще есть сисколы, которые уже так не перекинешь.

 

Конкурирующие потоки/процессы на одном ядре будут предпочтительнее конкурирующих за доступ к кешу ядер?

 

Никто не скажет наверняка. Все сильно индивидуально от кода. Но конечно в первом приближении два ядра лучше чем одно. Я говорю не о таком масштабе, я говорю о том что 16 ядер на одну память это уже много.

 

У зионов до 12 (или до 10?) ядер на один ИКП - и ничо.

 

У меня был небольшой опыт с 24 ядерными серверами (2х Xeon), там увы не так уж и сладко. Это больше маркетинг, своих денег оно не стоит.

 

Ессно, память - это просто память. Ибо нет практически взаимодействия между потоками. А один поток прекрасно разбирается со своей памятью, если ему ось помогает.

 

Для NUMA систем надо чтобы процессам выделялась память в нужном домене, в том в котором работает процесс. Я не знаю возможно ли это автоматически как-либо в текущий момент.

Но любая работа с сетью это в любом случае работа с кернелом и уже вполне так конкурентная. Даст ли это большой положительный эффект? 10 серверов лучше чем 10 ядер.

 

Ну микротик - там роутинг, и в общем случае в роутинге все упирается в латентность памяти (ну или кешей если DMA контроллер юзает кеш), а не в ядра. В качестве веб-сервера он бы показал себя куда интереснее...

 

Это,к сожалению, тоже лишь теоретически. Пока нету ни одного решения от тилеры для серверов-приложений основанных на Tile-GX. И вендоры почему-то не верят в успех.

Посчитать все особенности сложно, а вот налить линукс в CCR и запустить вебсервер было бы интересно. Кто-либо возьмется? :)

Share this post


Link to post
Share on other sites

Но на практике прерывания плавают по ядрам, если вы их руками не перемолотили куда надо.

Разница в принципе небольшая - плавают или нет. Сам факт, что пока одно ядро переключается на прерывание, обрабатывает его и потом переключается обратно, а остальные - молотят данные, не отвлекаясь.

 

Для NUMA систем надо чтобы процессам выделялась память в нужном домене, в том в котором работает процесс. Я не знаю возможно ли это автоматически как-либо в текущий момент.

Думаю, именно так и выделяется (если есть свободная память ессно). Иначе - что еще есть поддержка NUMA в ядре?

 

Но любая работа с сетью это в любом случае работа с кернелом и уже вполне так конкурентная.

50-100 мбит/с на отдаче динамики - это не работа с сетью :) Это - так, чих.

 

Пока нету ни одного решения от тилеры для серверов-приложений основанных на Tile-GX. И вендоры почему-то не верят в успех.

Скорее всего - потому что нет ни одного дистра, а мэйнтэйнить его никто не хочет. Тилера сама должна была бы по хорошему родить рефренс платформу (пускай и ограниченным тиражом, на пощупать) и как-то портировать какой-либо из актуальных дистров (хоть дебиан) - тогда бы все взлетело. Тем более, их тайл про смотрится довольно вкусно....

Share this post


Link to post
Share on other sites

Тут про php народ написал, это убийство, оно на любом процессоре тормоз полный, потому что гладиолус, можно спорить как по производительности статический линкарь на сях или сях с плюсами работать будет, или на худой конец Ява, или что то что компилируется. А пхп оно и в Африке больше 10, максимум 20 запросов в секунду не тащит. Потому что пэхапэ... И по секунде или две время генерации страниц такого убожества как umi или по подчеркнула у других, это убийство. Если интересно то возьмите лоад раннер и напишите нормальные тесты и увидите что оно мертво рожденное даже мерзенькая винда на c# веселее из под iis работает чем пхп на любом юниксе и беда не в юниксе...

UMI - это да , шедевр - сталкивался недавно. Думал что typo3 или bitrix чемпионы по тормознутости - ан нет , можно сделать еще хуже :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this