Hazelcast работает медленно при размещении данных в распределенной карте

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


java hazelcast
person Lê Viết Khánh    schedule 23.10.2018    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

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

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

person Rishabh Agarwal    schedule 23.10.2018
comment
Я использую асинхронные резервные копии, рядом с кешем для моего imap. Я запускаю hazelcast как экземпляр для встраивания. Но ввод данных на карту происходит медленно, примерно 2 000 операций в секунду. - person Lê Viết Khánh; 23.10.2018
comment
Можете ли вы распечатать всю конфигурацию, которая у вас есть для экземпляра hazelcast. - person Rishabh Agarwal; 23.10.2018
comment
я размещаю его в ответе ниже. - person Lê Viết Khánh; 23.10.2018
comment
Не вижу какой-либо конкретной причины для его замедления. посмотрите, может ли это помочь: stackoverflow.com/questions/42764205/ - person Rishabh Agarwal; 23.10.2018

arrow_upward
0
arrow_downward

Я запускаю экземпляр для встраивания, используя сериализуемые данные, ключ — строка [25 символов], значение — объект {строка [25 символов], строка [25 символов]}

    <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>
person Lê Viết Khánh    schedule 23.10.2018
comment
можете ли вы проверить это снова, установив in-memory-format в BINARY? Кроме того, вы используете клиент Hazelcast для своих тестов? Можете ли вы также поделиться тестовым кодом, который вы используете? Вы упомянули, что используете встроенные элементы с 4 ядрами каждый. Можете ли вы поделиться полными характеристиками системы, чтобы я мог проверить? Пока проведу аналогичный тест. - person Gokhan Oner; 24.10.2018