Hazelcast - Несогласованная пропускная способность для распределенной карты

Question

Я использую версию Hazelcast версии 3.3 (с открытым исходным кодом) и сталкиваюсь с проблемой с непоследовательной пропускной способностью для распределенной карты.

У меня есть один экземпляр кеша, и на одном конце приложение помещает данные в кеш (со скоростью 1000 объектов каждые 1 мин), а на другом конце другое приложение получает данные с карты (со скоростью несколько 100 раз в секунду). Объекты Java используют стандартную сериализацию Java и формат памяти в виде BINARY.

Извлечение данных прекрасно работает для большинства операций «получить», где требуется менее 1 мс, однако иногда операция «получить» занимает до 20 мс для извлечения одних и тех же данных. Это экстремальное поведение неприемлемо, поскольку я не могу отложить обработку, потому что случайная выборка заняла больше времени, чем ожидалось.

Я ищу вперед для прогнозируемой/согласованной пропускной способности при извлечении данных; случайный всплеск в получении данных из экземпляра Hazelcast неприемлем. Если кто-то сталкивался с той же проблемой и имеет указатели, пожалуйста, поделитесь.

Answer 1

Я сделал 2 изменения на проекте.

первый я изменил сериализации от java.io.Serializable до com.hazelcast.nio.serialization.DataSerializable второй я ввел Java разогреть время. Я обращаюсь к полной карте несколько раз во время запуска, прежде чем actaully использовать в приложении.

С этими изменениями я вижу хорошее улучшение производительности.

Answer 2

у вас есть журнал GC? Это вполне может быть вызвано паузой, введенной сборщиком мусора. На HotSpot (Sun/Oracle Java) можно включить журнал, начиная JVM с этими флагами:

-Xloggc:/path/to/file/gc.log -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails 

Он будет производить журнал с GC событий, так что вы можете попытаться соотнести необычно высокие латентности с GC паузах.

Если вы также можете попробовать использовать этот включатель:

-XX:+PrintGCApplicationStoppedTime 

Он будет сообщать о все JVM делает паузу, а не только в паузах, спровоцированные Garbage Collector.