Неравномерное разбиение данных в Apache Ignite 2.4 приводит к тому, что узлам не хватает памяти и происходит сбой - PullRequest
0 голосов
/ 09 мая 2018

Окружающая среда:

  1. Apache Ignite 2.4 работает на Amazon Linux. ВМ 16CPUs / 122 ГБ оперативной памяти. Там много места.
  2. 5 узлов, 12 ГБ каждый
  3. cacheMode = PARTITIONED
  4. backups = 0
  5. OnheapCacheEnabled = true
  6. atomicityMode = ATOMIC
  7. rebalacneMode = SYNC
  8. rebalanceBatchSize = 1MB
  9. copyOnread = false
  10. rebalanceThrottle = 0
  11. rebalanceThreadPoolSize = 4

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

Количество элементов в кеше более или менее стабильно с течением времени (есть небольшое колебание, поскольку у нас есть смесь событий создания, обновления и удаления), но мы заметили, что распределение данных по разные узлы очень неровные, причем один из узлов имеет по крайней мере удвоенное количество ключей (и использование памяти) по сравнению с другими. Со временем этому узлу либо не хватает памяти, либо он начинает выполнять очень длинные GC и теряет связь с остальной частью кластера.

Я ожидал, что Ignite уравновесит данные между различными узлами, но реальность показывает что-то совершенно другое. Я что-то здесь упускаю? Почему мы видим этот дисбаланс и как мы можем это исправить?

Заранее спасибо.

1 Ответ

0 голосов
/ 08 июня 2018

Итог, хотя наша хеш-функция имела хорошее распределение, функция сродства по умолчанию не давала хорошего распределения ключей (и, следовательно, памяти) по узлам в кластере. Мы заменили его на очень наивный (partition # % # of nodes), и это немного улучшило распределение (менее 2% дисперсии).

Это не общее решение; это работает для нас, потому что весь наш кластер находится в одной виртуальной машине, и мы не используем репликацию. Для массивных кластеров, пересекающих границы ВМ и репликацию, хранение реплицированных данных на отдельных серверах является обязательным, и наивный подход не сократит это.

...