2015-10-15 3 views
0

Infinispan версия 6.0.2.FinalInfinispan производительность

Ищу в вопрос, где Infinispan положить операции иногда занимает больше времени, чем на секунду.

У кластера есть 4 узла, и мы используем режим репликации. У нас есть 2 приложения на каждом из 4 узлов, которые используют встроенный Infinispan.

Общая производительность вполне нормально, так как среднее значение для всех операций Infinispan составляет около 2-3 мс. Ниже приведен один пример:

2015-10-15 16: 29: 02048 ОТЛАДКА InfinispanCacheListener [REQ-23] Infinispan кэша: @CacheEntryCreated, cacheName = дублировать, ключ = ключа; 1810328342; 356091; -828608960-0

2015-10-15 16: 29: 02048 DEBUG InfinispanCacheListener [Req-23] Infinispan кэш: @CacheEntryModified, cacheName = дублировать, ключ = ключ; 1810328342; 356091; -828608960-0

2015-10-15 16: 29: 03,606 DEBUG InfinispanCacheListener [Req-23] Кэш-память Infinispan: @CacheEntryModified, cacheName = дубликат, ключ = ключ; 1810328342; 356091; -828608960-0

20 15-10-15 16: 29: 03606 DEBUG InfinispanCacheListener [Req-23] Infinispan кэш: @CacheEntryCreated, cacheName = дублировать, ключ = ключ; 1810328342; 356091; -828608960-0

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

В промежутке между операциями Infinispan выполняется очень быстро, пример ниже.

2015-10-15 16: 29: 02051 ОТЛАДКА InfinispanCacheListener [удаленная-нить-425] кэш Infinispan: @CacheEntryCreated, cacheName = ответ, ключ = ключ; 1810328342; 356085; -828608958-0

2015 -10-15 16: 29: 02,051 DEBUG InfinispanCacheListener [remote-thread-425] Кэш Infinispan: @CacheEntryModified, cacheName = ответ, ключ = ключ; 1810328342; 356085; -828608958-0

2015-10-15 16 : 29: 02,051 DEBUG InfinispanCacheListener [remote-thread-425] Кэш Infinispan: @CacheEntryModified, cacheName = ответ, ключ = ключ; 1810328342; 356085; -828608958-0

2015-10-15 16: 29: 02051 DEBUG InfinispanCacheListener [удаленный-токарно-425] кэш Infinispan: @CacheEntryCreated, cacheName = ответ, ключ = ключ; 1810328342; 356085; -828608958-0

  1. Я хотел бы чтобы узнать, как найти, что вызывает эти шипы. Есть ли обычные подозреваемые?
  2. Почему в первом примере событие сообщается потоком приложения и во втором примере, сообщаемом удаленной нитью? Я видел, что иногда это сообщается потоками OOB. Оба события локально сгенерированы.

Благодаря Ракеш

ответ

2

Я предполагаю, что это кластерные слушатели, не так ли? Если локальный узел является основным владельцем ключа, он может запускать локальные слушатели непосредственно из потока приложений, который выдает операцию. Если основным владельцем является удаленный узел, он должен отправить сообщение исходному узлу, и это будет обработано в пуле удаленных потоков.Когда пул потоков исчерпан, OOB-поток должен вызывать это, поскольку пул удаленных потоков использует политику запуска вызывающего абонента. Вот почему вы видите разные потоки, вызывающие слушателя.

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

+0

Нет, это не сгруппированные слушатели. Не поддерживается ли кластерный слушатель в 7.0? – Rakesh

Смежные вопросы