[Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов

[Анатолий Гришаев]

09.02.2015 16:43, Alexander Lourier пишет:
>
>     > Добавлять воркеров я уже не могу - их 50 штук на сервере
>     выполняется, и
>     > больше уже памяти нет.
>     Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному
>     приложению эта память не понадобится? Может, и синхронному не нужна?
>
>
> Онлайн-игра. В ней есть много локаций (на данный момент сейчас их 
> 130518 штук). Про каждую локацию есть примерно килобайт данных. Игрок 
> может сделать запрос на прокладку пути из пункта A в пункт B. Надо 
> загрузить граф локаций, сделать поиск по нему, вернуть ответ игроку.
>
> Связность локаций постоянно меняется (игроки открывают/закрывают 
> порталы), и граф надо перестраивать. Поэтому загрузить его один раз, а 
> потом отфоркать воркеров уже не получается. Поэтому каждый воркер 
> должен держать в памяти копию. 130 мегабайт. И это не единственные 
> полезные вещи, которые в памяти оседают. Есть и ещё всякое. В 
> результате 50 воркеров едят 10 гигов памяти.
>
> Для решения этой проблемы у меня прокладкой пути занимается отдельный 
> сервис, который единственный держит в памяти граф всего мира. 
> Недостаток этого решения - latency. Если несколько клиентов хотят 
> проложить путь, они это делают по очереди, а процессоры воркеров в это 
> время простаивают.
>
> Если бы воркеры были асинхронными, то можно было бы запустить 8 
> воркеров (по числу ядер на машине), и на каждый воркер хранилась бы 
> всего одна копия графа. Внезапно высвободилась бы куча памяти, которой 
> бы нашлось лучшее применение (дисковые кэши, memcached и т.д.)
>
>
Вау, мы такую задачу решали на перле лет этак 6 назад.
prefork + map + async + немного xs.
Решили так:
1) маппили файл с графом на память
2) prefork
3) перед тем как найти путь или перестроить граф делали flock ( для 
изменения LOCK_EX, для построения LOCK_SH)
4) поиск пути делался XS функцей(получалось сильно быстрее), а все 
остальное на perl

1) В итоге граф не клонируется между форками
2) Все процессоры могут поучаствовать в расчете пути.
3) единственный минус изменение пути может выполнять один процессор.

В принципе flock можно заменить на более прикольные блокировки.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150209/c7fb5852/attachment.html>