<html>
<head>
<meta content="text/html; charset=koi8-r" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">09.02.2015 16:43, Alexander Lourier
пишет:<br>
</div>
<blockquote
cite="mid:CANLU1qH0qaLozj91adZLpRgop1n7wR+xHvCY6KvfQaHxvXbCqA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">>
Добавлять воркеров я уже не могу - их 50 штук на сервере
выполняется, и<br>
> больше уже памяти нет.<br>
Хочу подробностей! Что это за воркеры такие злые? Почему
асинхронному<br>
приложению эта память не понадобится? Может, и синхронному
не нужна?<br>
</blockquote>
<div><br>
</div>
<div><span style="font-size:13.1999998092651px">Онлайн-игра. В
ней есть много локаций (на данный момент сейчас их 130518
штук). Про каждую локацию есть примерно килобайт данных.
Игрок может сделать запрос на прокладку пути из пункта A в
пункт B. Надо загрузить граф локаций, сделать поиск по
нему, вернуть ответ игроку. </span></div>
<div><span style="font-size:13.1999998092651px"><br>
</span></div>
<div>Связность локаций постоянно меняется (игроки
открывают/закрывают порталы), и граф надо перестраивать.
Поэтому загрузить его один раз, а потом отфоркать воркеров
уже не получается. Поэтому каждый воркер должен держать в
памяти копию. 130 мегабайт. И это не единственные полезные
вещи, которые в памяти оседают. Есть и ещё всякое. В
результате 50 воркеров едят 10 гигов памяти.</div>
<div><br>
</div>
<div>Для решения этой проблемы у меня прокладкой пути
занимается отдельный сервис, который единственный держит в
памяти граф всего мира. Недостаток этого решения - latency.
Если несколько клиентов хотят проложить путь, они это делают
по очереди, а процессоры воркеров в это время простаивают.</div>
<div><br>
</div>
<div>Если бы воркеры были асинхронными, то можно было бы
запустить 8 воркеров (по числу ядер на машине), и на каждый
воркер хранилась бы всего одна копия графа. Внезапно
высвободилась бы куча памяти, которой бы нашлось лучшее
применение (дисковые кэши, memcached и т.д.)</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
Вау, мы такую задачу решали на перле лет этак 6 назад.<br>
prefork + map + async + немного xs.<br>
Решили так:<br>
1) маппили файл с графом на память <br>
2) prefork <br>
3) перед тем как найти путь или перестроить граф делали flock ( для
изменения LOCK_EX, для построения LOCK_SH)<br>
4) поиск пути делался XS функцей(получалось сильно быстрее), а все
остальное на perl<br>
<br>
1) В итоге граф не клонируется между форками<br>
2) Все процессоры могут поучаствовать в расчете пути.<br>
3) единственный минус изменение пути может выполнять один процессор.<br>
<br>
В принципе flock можно заменить на более прикольные блокировки.<br>
</body>
</html>