> > > Добавлять воркеров я уже не могу - их 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) единственный минус изменение пути может выполнять один процессор. >
Угу, хорошее решение. По факту, возможности, отсутствующие в перле (разделение данных), вы переписали на C.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
