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 можно заменить на более прикольные блокировки.
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
