[alex_001]

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

 

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

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

 

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

[dignity]

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

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

[alkanaft]

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

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

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

 

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

[alex_001]

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

[NiTr0]

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

 

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

[SergeiK]

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

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

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

 

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

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

 

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

 

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

[alkanaft]

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

[DVM-Avgoor]

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

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

[alkanaft]

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

[NiTr0]

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

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

 

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

[alex_001]

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

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

[DVM-Avgoor]

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

 

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

 

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

 

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

[SergeiK]

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

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

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

 

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

[NiTr0]

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

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

 

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

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

 

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

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

[alkanaft]

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

[DVM-Avgoor]

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

 

 

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

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

[NiTr0]

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

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

 

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

[DVM-Avgoor]

Дык кол-во пакетов будет то же самое что для одого ядра, что для десятка. Только одно но - когда 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ядрах, на которые сыпятся интеррапты).

[NiTr0]

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

[DVM-Avgoor]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

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

[NiTr0]

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

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

 

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

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

 

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

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

 

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

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

[alex_001]

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

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