Проблемы с операциями GridGain

Question

В нашем проекте мы тестируем, как транзакции работают в распределенной среде. В рамках проекта мы тестируем версию с открытым исходным кодом GridGain 6.5.5.

Мы столкнулись с множеством проблем в следующем TestCase:

1. Мы тестируем кэш без каких-либо дополнительных правил.
2. В кэше хранится id-String как ключ, а BigDecimal - как значение.
3. Мы тестируем базовые операции (сложение и вычитание) на значения первого кеша из 6, 12 и 18 клиентов. Одна операция выглядит как «вычесть X из A, добавить X в B».
4. Приложение GridGain развернуто как .war файл в WildFly.
5. Клиенты подключаются к WildFly с развернутым GridGain с использованием HTTP и отправляют список операций (мы тестируем партии с 1 операцией, 50, 500, 1000, 5000 операций).
6. Мы тестируем многоуровневый многоуровневый режим с транзакциями, файлы конфигурации, которые мы использовали, прилагаются далее.
7. Мы проверили как пессимистические, так и оптимистичные транзакции отдельно.
8. Мы называем значения результатов «согласованными», если они равны фиктивному режиму: один клиент, пакет 1, один узел. У нас есть фиктивная программа для перекрестной проверки (ее результаты в этом режиме всегда равны GridGain в локальном режиме).

вопросы являются:

1. Если мы делаем сделку как есть (вычесть из одного значения ключей, добавьте к другому), мы сталкиваемся с двумя проблемами: тупики и непоследовательность, если мы не получаем тупики , Количество несогласованных значений невелико, но мы не можем этого избежать - это около 12 на 1000 ключевых значений.
2. Если мы преобразуем наши запросы для сортировки по ключевым словам в каждом клиенте (поэтому порядок действий может измениться), мы можем избежать взаимоблокировок и несогласованности. Но у нас возникают другие проблемы: если пакет не менее 500, у нас есть неудачные транзакционные сбои. Если пакет мал, у нас GridGain полностью не работает (он не отвечает на текущий запрос).
3. Все работает очень медленно, и у нас почти нет нагрузки на процессор одновременно (около 6 секунд для пакетной = 1000 операций). Это нормально?

Наше оборудование:

ого Dell M620 лезвие, 256GB RAM, ядро ​​2x8 Xeon E2650v2, 10GbE сеть.

Придает:

1. GridGain оптимистичным конфигурации: https://gist.github.com/al-indigo/a2824aa62a3af8b18932
2. GridGain пессимистично конфигурации: то же самое, но с
3. журнал GridGain для второго выпуска: https://gist.github.com/al-indigo/233058772418fba8d341

Answer 1

(Moving от комментарий)

Чтобы избежать блокировок, вам необходимо убедиться, что вы приобретаете блокировки в том же порядке. Это необходимо делать при работе с транзакциями в любой системе записей, будь то база данных Oracle или сетка данных GridGain.

Что касается производительности, это должно быть очень быстро. Скорее всего, это вопрос конфигурации. Могу ли я попросить вас представить воспроизводимый пример? (Вы можете использовать pastbin.com поделиться кодом)

Answer 2

Я посмотрел на журналах и вижу следующей J параметры

-Xms64m -Xmx512m -XX:MaxPermSize=256m 

С высокой степенью вероятности вы работаете в длинные GC паузы, и это вероятная причина, по которой вы получаете исключения таймаута блокировки. С такими настройками памяти JVM может перейти в GC-паузы в течение 5 минут, в течение которых мир заблокирован и ничего не может быть сделано. Чтобы убедиться в этом, можно собрать журналы GC, используя следующие параметры виртуальной машины Java:

-Xloggc:/opt/server/logs/gc.log \ 
-verbose:gc \ 
-XX:+PrintGC \ 
-XX:+PrintGCTimeStamps \ 
-XX:+PrintGCDetails 

Моя рекомендация состоит в том, чтобы выделить около максимум 10GB на JVM и запустить несколько экземпляров JVM. Вы также можете попытаться использовать вне памяти памяти функция GridGain и выделить большое пространство памяти за пределами основной кучи Java - http://doc.gridgain.org/latest/Off-Heap+Memory. Кроме того, пожалуйста, обратите внимание на параметры настройки GC здесь: http://doc.gridgain.org/latest/Performance+Tips#PerformanceTips-TuneGarbageCollection

Другое большое предложение заключается в том, что вы не должны делать отдельные получить (...) операции в транзакции, но сделать один GETALL (...) вызова вместо:

try (GridCacheTx tx = balanceCache.txStart()) { 

    /* 
    * ============================================== 
    * This while loop calls get(...) many times and acquires one lock at a time. 
    * It should be replaced with one getAll(...) call. 
    * =============================================== 
    */ 
    while (changes.hasNext()) { 
     Map.Entry<String, BigDecimal> ent = changes.next(); 

     BigDecimal oldBalance = balanceCache.get(ent.getKey()); 

     balanceCache.putx(ent.getKey(), oldBalance.add(ent.getValue())); 
    } 

    tx.commit(); 
} catch (GridException ex) { 
    throw new Exception("transaction failed", ex); 
}