<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"><div bgcolor="#FFFFFF" text="#000000"><blockquote 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></fieldset>
      <br>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    Вау, мы такую задачу решали на перле лет этак 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></div></blockquote><div><br></div><div>Угу, хорошее решение. По факту, возможности, отсутствующие в перле (разделение данных), вы переписали на C.</div><div><br></div></div></div>