На днях через ленту новостей получил ссылку на интересный блог-пост. Суть в том, что Erlang-приложение, которое отлично работало на 2-х ядерной машине, при переносе на 8-ми ядерную машину начало падать из-за нехватки памяти. Причина оказалась в том, что один из медленных Erlang-процессов успевал разгребать свою очередь сообщений, когда его нагружали процессы с 2-х ядер. Но как только инициаторы сообщений получили в свое распоряжение 8-мь ядер, они стали генерировать так много работы для этого медленного процессора, что его очередь заполнялась быстрее, чем он успевал ее чистить. В результате очередь сообщений сжирала всю свободную память и все приложение падало.
Этот пример является хорошим показателем того, насколько важно в агентной системе следить за тем, чтобы каждый агент получал не больше сообщений, чем способен обрабатывать. Т.е. важность задачи overloading control. Которая в SObjectizer4 пока не имеет штатного решения. В поисках такого решения родилась очередная идея.
Пользуясь случаем, хочу еще раз выразить благодарность Дмитрию Вьюкову (aka remark), который первым обратил мое внимание на важность данной проблемы.
PS. Упомянутый мной блог-пост примечателен еще одним наблюдением. Люди написали на Erlang-е некую message switching platform (чтобы под этим не понималось), производительность которой на 2-х ядрах составляет 140 транзакций в секунду. Что они считают достаточной. При переходе на 8-мь ядер они получили прирост до 700 транзакций в секунду. Что они оценивают как хорошую масштабируемость. Сложно, конечно, оценивать их производительность, не зная, что именно они делают. Но, учитывая, что при 700 т/cек. узким местом были ни БД, ни другие компоненты системы, можно сделать вывод, что 140 т/сек. – максимум, который дает именно Erlang, далеко не самый быстрый язык программирования. Т.е. если бы они взяли вместо Erlang-а что-то более производительное (в особенности C++ и SObjectizer), то изначально могли иметь показатели в районе 500-600 т/сек. Но, видимо, это хороший пример, когда скорость работы программистов гораздо важнее скорости работы создаваемой им программы. И это компенсируется более производительным железом…
7 комментариев:
P.S. у тебя написан очень интересно, будто саму запись в блоге ты не читал, цитирую: "disk IO may also be slower than receiving messages". Т.е. реально затыки были с записью логов, записывать минус всему языку целиком, как ты сделал, по меньшей мере некорректно.
Да, затыки были с записью логов. Поэтому процесс, который вел логи не успевал разгребать свою очередь сообщений, когда в нее начали писать процессы с 8-ми ядер. Это не проблема языка, это проблема конкретного приложения, которое не внедрило себе никаких средств overload control. Аналогичные проблемы есть и в SObjectizer-приложениях, и, думаю, в ScalaActor-приложениях, и т.д. Так что в этом плане я минусов Erlang-у не ставил.
Но, я уверен, если бы приложение делали на более быстром языке, первоначальный показатель в 140 транзакиций в секунду, был бы превзойден в несколько раз.
Хммм... ну вообще как по-моему, так слишком медленно...
Switching системы обычно могут обеспечивать 1000-10000 транзакций/сек на одно-процессорной системе... если, конечно, кто-то вообще ставит задачу производительности. Потоковое сохранение журнала на диск/в БД обычно тянет порядка 10^3-10^5 записей/сек. Если надо читать из БД, то это кэшируется в памяти и ещё быстрее. А так, извините, что можно делать 30'000'000 таков при обработке одной транзакции?!
2Dmitry V'jukov: а чем вообще занимаются switching-системы?
принимают из сети, отправляют в сеть, конвертируют, маршрутизируют, немного бизнес-логики, журналируют в БД и/или файлы...
140 т/с на двухядерной системе могло бы быть нормально, если бы они делали много вычислительной обработки... но тогда бы на Erlange это тоже бы было скорее всего не особо быстро
Но намёк я понял - как можно говорить, быстрая система или медленная, если даже не знаешь, что конкретно она делает... :)
2Dmitriy V'jukov: никаких намеков не было :) Я просто имел очень смутные представления о том, чем занимаются switching-системы.
И таки я с тобой согласен -- 140 т/сек на современной технике возможно только, если идет какая-то серьезная обработка (в первую очередь, вычислительная). И еще большой вопрос, выгодно ли для вычислительных задач использовать Erlang.
Отправить комментарий