?

Log in

No account? Create an account

Previous Entry | Next Entry

JS-Kit, Erlang, Amazon EC2

JS-Kit расширяется вширь, требуя новых боксов, новых колокейшнов, новых процессоров в топку его ненасытной пасти. Решили колокейшн больше не насиловать (в рэках недостаточно питания) а пойти в Amazon EC2.

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

Основой для теста был принят так называемый EC2 "Large instance". Заодно удалось обновить результаты предыдущей серии тестов [1, 2], ибо старая лошадка имела версию R11B-5, а новая — R12B-5. Плюс к тому, добавил более-менее стандартный тест Quad Ant, который решает задачу коммивояжёра прогоном через города стада муравьёв.

Для начала, вот весь файл результатов в CSV.

Для начала я задался перепроверкой результатов предыдущих тестов [1, 2] с использованием более новой версии Erlang VM: R12B-5.



Напомню в чём суть Lock теста: один (в случае Lock Sequential) либо одновременно N (в случае Lock Parallel) клиентских процессов пытаются залочить какой-то ресурс, общаясь с централизованным локером, который имеет пару таблиц ETS для запоминания того кто именно лочит какие именно ресурсы. Естественно, сам локер-процесс — это узкое место, а значит этот тест тестирует, по сути, одно ядро в системе (при non-SMP VM), либо поведение системы при lock contention за единственный ресурс (в случае SMP). Второе тоже важно, ибо показывает насколько просаживается перформанс на локах внутри Эрланга.

Вот результаты этого теста в графике:



Видим, как замечательно работает виртуализованная сущность Amazon EC2 Large Instance, причём на двух виртуальных ядрах. Все четыре варианта запуска Locker теста EC2 показал результатами в первой пятёрке.

Обратим внимание насколько несущественна просадка перформанса если мы на не-SMP системе упёрлись в узкое место, представляющее собой один процесс (зелёная полоска ненамного меньше синей для single, то есть для не-SMP виртуальных машин (erlang -smp disable)). Это касается всех машин, а не только виртуализованной EC2 сущности, так что тут плюс один не-SMP Эрлангу.

С другой стороны, на том же EC2 эксплуатация узкого горла на SMP VM ведёт к серьёзной деградации производительности. Сравните зелёную линию у третьей сверху системы, которая EC2 Native SMP. Практически в два раза хуже чем базовая производительность. Вывод: там, где нужно драться за ресурсы, Эрланг лучше использовать в не-SMP режиме, ибо иначе в два раза хуже будут результаты. А там, где драться не нужно (просто какая-то передача сообщений по цепочке, сравним для одной и той же системы byte/single с byte/SMP) — там всё равно заметная на глаз просадка (процентов 20-30).

Для тех кто в теме, данный график представляет наглядный пример почему я в ближайшее время не слезу со своего старенького лэптопа PowerBook G4 1.5 GHz. Вон он, в первой трети списка, выше серверного Xeon'а, Core2 Quad, Pentium D и всякой остальной чепухи.

Но всё-же, несмотря на то что Locker не является искусственным тестовым кодом (он используется в продакшне!), тест локера в отдельности не представляет слишком большого интереса, потому что, как правило, именно на локере наши процессы не дерутся, тормоза у них в других местах. Так что попробуем посмотреть на другой способ оценки производительности, на Quad Ant. Он-то явно искусственный, но зато хоть какое-то разнообразие в оценке будет.

Вот табличка, отсортированная по результатам последовательного кода Quad Ant:



А вот её графическое представление:



Вах, EC2 и тут на высоте! Все четыре первых места, как бы мы их не повернули, показывают на превосходство Large Instance EC2 над всеми физическими боксами (не самыми дешёвыми, кстати), которые есть у нас под рукой. И это, кстати, результат прогона одного процесса (Ant Sequential, ant:main/0). Места под ним немного перетасовались, и табличка теперь выглядит как будто это соревнование систем, а не отдельных режимов работы эрланга на разных микроархитектурах процессоров. Напоминаю: Ant Sequential — это прогон одного тяжёлого эрланговского потока, без message passing, без lock contention: сплошная математика и сборка мусора.

А вот теперь самое интересное. В первом тесте, Locker Sequential/Parallel, мы увидели как эрланг справляется с узким местом в виде центрального процесса с ETS-таблицами. Во втором тесте, Ant Sequential, мы увидели как Эрланг мучает машину тяжёлой однопроцессной математикой. Осталось теперь посмотреть на "чистый" параллелизм: что делает Эрланг если у него есть несколько абсолютно несвязанных друг с другом заданий.

Табличка, отсортированная по результатам параллельного (4 процесса) кода Quad Ant:



А вот её графическое представление:



И вот тут-то наступает небольшой кирдык, потому что наш двухкорный EC2 уходит со сцены довольно резво. Как и следовало предположить, на сцену выходят четырёхъядерные кнопки, естественно в SMP режиме. Здесь Core2 Quad рвёт серверный Xeon, обладая на 50% большей масштабируемостью. Сравнение не полностью корректно, ибо FreeBSD 7.x получше масштабируется чем FreeBSD 6.x. Но выяснять кто виноват — процессор или планировщик — в данном случае пока не буду. Впрочем, двухъядерный инстанс EC2 вполне адекватен, ибо его два камня дают практически ровно пятьдесят процентов от перформанса топового четырёхъядерного процессора в этом списке, Core2 Quad, и очень опасно приближаются к Xeon'у по абсолютным цифрам.

По батарее тестов есть один вывод: Xeon — не самый подходящий процессор для Эрланга. Леонид Егошин это подтверждает в приватном письме:
Во-первых, lmbench. Он показал, среди кучи другого, что xeon-ы хуже C2D по целочисленной арифметике и по переключению процессов в Linux. Integer — раза в 2 (ДВА!).

Я сварганил тест по переключению, он подтвердил проблему, и я увидел такой интересный эффект — 2 процесса, обменивающиеся сигналами идут 80-85 сек, а 4 копии этих же процессов на 4core идут 51 сек. Затем, если повязать 2 процесса одних на одно ядро, то они тоже начинают работать 42 сек.

И ещё, TCP/IP идёт хуже чем C2D, но тут я думаю виноват эффект переключения (TCP идёт в отдельном kernel процессе.

Всё, естественно, для сравнимых частот (2GHz-2.16GHz).

P.S. Core i7 ЕЩЁ хуже по переключению, чем Xeon'ы, тест 2 процесса * 4 копии идёт 5 (ПЯТЬ!) минут, а 8 копий одного — 45 сек.


Ну и, конечно, главный вывод: EC2 рулит, использовать для Эрланга можно и нужно.

  1. К вопросу о быстродействии Erlang (2007-10-31)
  2. Обновил табличку (2007-11-15)


UPD: Amazon EC2 Large vs. Small instances (2009-03-10)

Tags:

Comments

( 33 comments — Leave a comment )
kika
Mar. 11th, 2009 01:31 am (UTC)
  1. Вот жопа-то с Зионами
  2. Появился еще один стартап, который будет лежать когда ляжет Амазон :-)
lionet
Mar. 11th, 2009 01:37 am (UTC)
У нас задача — продаться обобщённому гуглу. Так что архитектура должна допускать переход на любую подложку. Сейчас подложка — colo + EC2, в перспективе — colo + обобщённый гуглобэк-енд.
(no subject) - kika - Mar. 11th, 2009 01:40 am (UTC) - Expand
(no subject) - lionet - Mar. 11th, 2009 01:45 am (UTC) - Expand
(no subject) - nponeccop - Mar. 12th, 2009 01:36 am (UTC) - Expand
(no subject) - lionet - Mar. 12th, 2009 01:43 am (UTC) - Expand
kika
Mar. 11th, 2009 01:32 am (UTC)
дело наверное не в зионах как таковых, а в их обвязке - чипсете и, главное, буферированной памяти.
lionet
Mar. 11th, 2009 01:38 am (UTC)
эка/система.
yakovis
Mar. 11th, 2009 01:36 am (UTC)
оффтопик: при попытке оставить тестовый комментарий у вас на сайте обнаружил, что нужно сначала отдельно войти с openid (например), а потом уже отправлять комментарий, а если этого не сделать, то, несмотря на введенный openid, комментарий отправится от гостя. мне кажется, что это неправильно, а вам?
lionet
Mar. 11th, 2009 01:38 am (UTC)
Мне тоже.
(no subject) - purpla_horsa - Mar. 11th, 2009 03:42 pm (UTC) - Expand
ex_ex_cqdx3
Mar. 11th, 2009 07:40 am (UTC)
32 СПАРК совсем слили :(
FreeBSD форева
lionet
Mar. 11th, 2009 07:43 am (UTC)
ну почему слили — на Locker тесте спарк 650 мегагерцовый едва ли не круче чем двухъядерный Pentium D о трёх гигагерцах!

мы сами его используем на полную мощность!
(no subject) - blacklion - Mar. 11th, 2009 10:39 am (UTC) - Expand
(no subject) - lionet - Mar. 11th, 2009 08:45 pm (UTC) - Expand
magic_tolik
Mar. 11th, 2009 10:42 am (UTC)
Очень полезный анализ. Большое спасибо!

Мы сами используем EC2 и Эрланг в нашем проекте Рисоваська: http://risovaska.ru
mpd
Mar. 11th, 2009 03:35 pm (UTC)
Предлагаю термин - эрлангоугодный процессор...
...ну и для симметрии - эрлангонеугодный или неэрлангоугодный.
Хотя, звучит немного неблагозвучно. :-(
nponeccop
Mar. 12th, 2009 01:32 am (UTC)
"Large instance" -- ccылка битая. Лишнее "На"

Что такое Xeon? На каком ядре? Бренд Xeon существует со времен PII.


lionet
Mar. 12th, 2009 01:36 am (UTC)
E5420, Harpertown
dimsmol
Mar. 12th, 2009 07:25 am (UTC)
Спасибо, очень интересно!

Забавный факт - многие интернет-стартапщики, которым я рассказывал о "Рисоваське", уверяли меня что при выходе на хорошую нагрузку EC2 оказывается безумно дорогим решением по сравнению с colocation, а у вас все наоборот - рост привел в EC2 :-)
lionet
Mar. 12th, 2009 07:58 am (UTC)
По нашим расчётам, EC2 примерно эквивалентен покупке неплохих серверов в колокейшн каждые два года.

То есть, если ты купил рэк серверов и используешь их три года, то смысла в EC2 нет. Если ты купил рэк серверов и через полтора года заменил на пять более мощных серверов — то смысл уже есть. Расчёт идёт по стоимости colocation (рэка), плюс стоимость серверов (1 штука x $2k), плюс трафик.

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

И так далее. То есть, они правы по сути (EC2 дороже чем colo), но конкретная экономика решения зависит это не столько от нагрузки, сколько от параметров стандартной формулы rent versus buy.
(no subject) - dimsmol - Mar. 14th, 2009 01:13 pm (UTC) - Expand
(no subject) - lionet - Mar. 15th, 2009 12:12 am (UTC) - Expand
(no subject) - lionet - Mar. 15th, 2009 12:14 am (UTC) - Expand
Odobenus Rosmarus (rosmarus) [blogspot.com]
Apr. 17th, 2009 03:18 am (UTC)
Есть предложение для лучшего представления данных, перед каждой таблицей писать в каких единицах результаты измерения. И добавлять что нибудь типа "больше значение == лучше результат" или типа того.

Иначе приходится тратить довольно много времени, чтобы разобраться. Особенно если не читал предыдущие статьи.
lionet
Apr. 17th, 2009 03:37 am (UTC)
Хорошее замечание, учту. Спасибо!
zyxman
Jun. 30th, 2009 03:01 pm (UTC)
вопрос по приложению erlang
Здравствуйте!

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

Задача - игровой сервер.
Карта местности с ~40 тыс. взаимодействующих NPC и от сотен до тысяч игроков (NPC = автомат или бот, большинство NPC не выходят за пределы некоторой заранее выделенной области, NPC распределены относительно равномерно, игрок отличается от NPC тем что управляется по TCP/IP с удаленного клиента и игроки могут ходить толпами).
Размеры карты - порядка сотни максимальных дальностей видимости игрока по любой координате (то есть объектов в конкретный момент видящих другой объект не очень много).
Интенсивная обработка взаимной видимости объектов (в общем случае каждый должен знать набор объектов вокруг него в заданном радиусе и уметь обрабатывать события появления заданного вида объектов в поле зрения и исезновение их. Например, монстр может атаковать появившегося в поле его зрения игрока, NPC-охранник в городе атаковать монстра и т.п.).
...
Сейчас реализовано на Java.
"Атака замка - это плотно взаимодействующие сотни активных объектов. У нас же проблемы возникают уже на десятках."
http://balancer.ru/tech/forum/2009/06/t36110--Ischem-yazyk-programmirovaniya-pod-zadac.1526.html

Вопрос: можно ли по тесту Quad Ant прикинуть железо необходимое для решения этой задачи на Erlang?
- Оно вроде очень похоже на приложение того вида для которых Erlang делался и должен хорошо удобно, надежно и быстро исполнять, но уверенности нет..
lionet
Jun. 30th, 2009 05:09 pm (UTC)
Re: вопрос по приложению erlang
Куча неизвестных. Неизвестна сложность основных алгоритмов, связность картины, etc. Нужно больше данных. Пиши телефон в приват, разберемся.
levgem
Sep. 22nd, 2009 01:20 pm (UTC)
Лев, в эту таблицу стоит внести Core i7. У нас они показывают двухкратное ускорение.
lionet
Sep. 22nd, 2009 01:24 pm (UTC)
1. По сравнению с чем?
2. У меня нет доступа к произвольной аппаратуре; Core 7 пока нет.
(no subject) - levgem - Sep. 22nd, 2009 01:38 pm (UTC) - Expand
( 33 comments — Leave a comment )

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031
Powered by LiveJournal.com
Designed by yoksel