Hazelcast работает медленно, когда помещает данные в распределенную карту - PullRequest
Новая
       7

Hazelcast работает медленно, когда помещает данные в распределенную карту

0 голосов
/ 23 октября 2018

У меня есть два узла Hazelcast (16 ГБ ОЗУ, 4 ядра на узел). Когда я пытался поместить на распределенную карту, Hazelcast был очень медленным (1904 операций / с), но если я отключил один узел, производительность повысилась (30000 операций /с).Кто-нибудь может помочь мне превратить производительность в несколько узлов?Спасибо

Ответы [ 2 ]

0 голосов
/ 23 октября 2018

Я запускаю встраиваемый экземпляр, используя data-serializable, ключ - String [25chars], значение: Object {String [25chars], String [25 chars]} 

    <in-memory-format>OBJECT</in-memory-format>


    <backup-count>0</backup-count>

    <async-backup-count>1</async-backup-count>
    <!--
        Maximum number of seconds for each entry to stay in the map. Entries that are
        older than <time-to-live-seconds> and not updated for <time-to-live-seconds>
        will getMSISDN automatically evicted from the map.
        Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0
    -->
    <time-to-live-seconds>864000</time-to-live-seconds>
    <!--
        Maximum number of seconds for each entry to stay idle in the map. Entries that are
        idle(not touched) for more than <max-idle-seconds> will getMSISDN
        automatically evicted from the map. Entry is touched if getMSISDN, putMSISDN or containsKey is called.
        Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.
    -->
    <max-idle-seconds>864000</max-idle-seconds>
    <!--
        Valid values are:
        NONE (no eviction),
        LRU (Least Recently Used),
        LFU (Least Frequently Used).
        NONE is the default.
    -->
    <eviction-policy>LRU</eviction-policy>

    <near-cache>
        <max-size>0</max-size>
        <time-to-live-seconds>864000</time-to-live-seconds>
        <max-idle-seconds>864000</max-idle-seconds>
        <eviction-policy>LRU</eviction-policy>
        <invalidate-on-change>true</invalidate-on-change>
        <in-memory-format>BINARY</in-memory-format>
        <cache-local-entries>false</cache-local-entries>
        <eviction size="1000" max-size-policy="ENTRY_COUNT" eviction-policy="LFU"/>
    </near-cache>
</map>
0 голосов
/ 23 октября 2018

Пожалуйста, проверьте ваши конфигурации.У вас должно быть синхронное резервное копирование , в результате ваш положительный запрос будет завершен, когда данные будут реплицированы на другой узел.Это конфигурация по умолчанию.

Вы можете использовать асинхронное резервное копирование для повышения производительности.Но это будет препятствовать согласованности системы.

Дополнительная информация о согласованности:

В контексте теоремы CAP Hazelcast является AP продукт.Таким образом, Согласованность наилучшего из возможных нацелена на репликацию, а резервные копии sync и async являются реализациями модели отложенной репликации .Как это объясняется на странице;разница между двумя вариантами составляет:

  • Синхронизация резервных копий , блок вызывающей стороны до тех пор, пока обновления резервной копии не будут применены репликами резервных копий, и подтверждения не будут отправлены обратно вызывающей стороне
  • Асинхронное резервное копирование работает как огонь и забудьте.Ниже см. Часть из Справочного руководства Hazelcast :

Техника репликации Hazelcast позволяет кластерам Hazelcast обеспечивать высокую пропускную способность.Однако из-за временных ситуаций в системе, таких как прерывание работы сети, резервные копии могут пропускать некоторые обновления и расходиться с первичными.Резервные копии также могут попадать в длинные GC-паузы или VM-паузы и отставать от основного, что называется ситуацией, называемой задержкой репликации.Если основной элемент реплики раздела Hazelcast дает сбой во время задержки репликации между ним и резервными копиями, может быть потеряна строгая согласованность данных.

...