Предикат Hazelcast зависает во время тяжелой нагрузки

У меня есть двухузловой кластер Hazelcast с размером кучи 6 ГБ каждый. У меня есть предикат, который работает с четырьмя полями, поэтому, например, цель, давайте рассмотрим класс Employee

  public class Employee {
  String id,
  String name,
  String surname,
  String timestamp
  .....
  }

Класс имеет в общей сложности 13 полей или около того. Я запускаю запрос диапазона по отметке времени и абсолютному совпадению с другими 3 полями - id , имя и фамилия. Для сериализации я использую IdentifiedDataSerializable, поскольку это наиболее эффективная форма сериализации, которую может предложить hazelcast. У меня есть установка контейнера сервлета tomcat, поэтому каждый поступающий запрос запускает предикат в кластере. Проблема, с которой я сейчас сталкиваюсь, заключается в том, что когда в кластере около 100 000 записей, и я провожу тест производительности в контейнере tomcat, большинство потоков tomcat зависают, поскольку запрос предиката никогда не возвращается. Я просмотрел модель потоков, предоставляемую hazelcast — https://docs.hazelcast.org/docs/latest-dev/manual/html-single/index.html#threading-model . Я возился с различными типами потоков, используя свойства в документации, и это улучшило ситуацию, но в основном это было в темноте. Я добавил индекс для идентификатора поля, но это тоже не улучшает ситуацию.

Я был бы очень признателен, если бы кто-то указал мне правильное направление, как я мог бы решить эту проблему. Заранее спасибо!

РЕДАКТИРОВАТЬ -

Версия Hazelcast, используемая как для кластера, так и для клиента, — 3.9. Кроме того, я использую hazelcast, встроенный в приложение весенней загрузки. Не думаю, что это будет иметь какой-то эффект, но хотел, чтобы вы все знали.


person Indraneel Bende    schedule 09.02.2019    source источник
comment
Можете ли вы проверить состояние потоков серверов в дампах потоков? Где они застряли? Серверы Hazelcast также печатают диагностические журналы, которые также полезны при расследовании зависших ситуаций, поскольку они сообщают вам, какие операции зависли и какие операции накапливаются. Также проверьте серверы на наличие их журналов GC, это вполне могут быть паузы gc, которые блокируют серверные JVM от любой обработки. Добавление индексов к полям, которые вы используете в предикатах, помогает значительно повысить производительность.   -  person wildnez    schedule 09.02.2019
comment
Слово предостережения — я бы не стал возиться с внутренними исполнителями, пока мы не узнаем, что и где вызывает блокировку предиката, и все другие решения не сработали.   -  person wildnez    schedule 09.02.2019
comment
хорошо, спасибо, я посмотрю и вернусь к вам.   -  person Indraneel Bende    schedule 10.02.2019
comment
Кроме того, было бы полезно, если бы вы предоставили код предиката и конфигурацию карты.   -  person Ozan Kılıç    schedule 11.02.2019
comment
К сожалению, я не смогу поделиться кодом предиката. Все, что я могу вам сказать, это то, что я использую predicateBuilder и EntryObject для создания предиката. И, как я объяснил в вопросе, это абсолютное совпадение по 3 полям и запрос диапазона по отметке времени.   -  person Indraneel Bende    schedule 11.02.2019
comment
Что касается конфигурации карты, на карте есть прослушиватель записей, и я добавил индекс для идентификатора поля. Кроме того, он принимает все значения по умолчанию.   -  person Indraneel Bende    schedule 11.02.2019
comment
Отредактировал вопрос с версией hazelcast, которую я использую.   -  person Indraneel Bende    schedule 11.02.2019


Ответы (1)


@Indraneel-Bende, пара предложений:

  1. Механизм запросов Hazelcast оценивает все предикаты и объединяет результаты. Если это предикат AND, после получения всех 4 результатов Predicate будут выбраны общие для всех 4 результатов. Таким образом, если какое-либо из этих полей имеет низкую кардинальность и возвращает слишком много результатов, это замедлит предикат. Итак, я бы предложил определить индекс только для 1 поля с наибольшей кардинальностью или не более чем для 2 полей.
  2. Поскольку не все поля будут проиндексированы, записи, возвращаемые из хранилища индексов, необходимо десериализовать, чтобы применить неиндексированные предикаты. Даже с IdentifiedDataSerializable, если у вас слишком много полей, вы будете каждый раз оплачивать полную стоимость десериализации. Вместо этого вы можете реализовать Portable сериализацию. Хотя размер сохраненной записи будет больше, таким образом участники Hazelcast смогут десериализовать только те поля, которые вы используете в этих предикатах, и это ускорит запросы.
  3. Как описано здесь, https://docs.hazelcast.org/docs/3.9/manual/html-single/index.html#copying-indexes, результаты индексирования копируются, чтобы убедиться, что результаты правильные, особенно новые узлы присоединяются к кластеру или покидают его. Если вы уверены, что членство не изменится, вы можете установить hazelcast.index.copy.behavior на NEVER. Это также ускорит запросы.

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

person Gokhan Oner    schedule 12.02.2019