воскресенье, 4 января 2009 г.

Очередные мысли о защите агентов от перегрузки

На днях через ленту новостей получил ссылку на интересный блог-пост. Суть в том, что 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 транзакиций в секунду, был бы превзойден в несколько раз.

Dmitriy V'jukov комментирует...

Хммм... ну вообще как по-моему, так слишком медленно...
Switching системы обычно могут обеспечивать 1000-10000 транзакций/сек на одно-процессорной системе... если, конечно, кто-то вообще ставит задачу производительности. Потоковое сохранение журнала на диск/в БД обычно тянет порядка 10^3-10^5 записей/сек. Если надо читать из БД, то это кэшируется в памяти и ещё быстрее. А так, извините, что можно делать 30'000'000 таков при обработке одной транзакции?!

Евгений Охотников комментирует...

2Dmitry V'jukov: а чем вообще занимаются switching-системы?

Dmitriy V'jukov комментирует...

принимают из сети, отправляют в сеть, конвертируют, маршрутизируют, немного бизнес-логики, журналируют в БД и/или файлы...
140 т/с на двухядерной системе могло бы быть нормально, если бы они делали много вычислительной обработки... но тогда бы на Erlange это тоже бы было скорее всего не особо быстро

Dmitriy V'jukov комментирует...

Но намёк я понял - как можно говорить, быстрая система или медленная, если даже не знаешь, что конкретно она делает... :)

Евгений Охотников комментирует...

2Dmitriy V'jukov: никаких намеков не было :) Я просто имел очень смутные представления о том, чем занимаются switching-системы.

И таки я с тобой согласен -- 140 т/сек на современной технике возможно только, если идет какая-то серьезная обработка (в первую очередь, вычислительная). И еще большой вопрос, выгодно ли для вычислительных задач использовать Erlang.