Hazelcast хранит большие объекты, что приводит к большой задержке - PullRequest
Новая
       8

Hazelcast хранит большие объекты, что приводит к большой задержке

0 голосов
/ 01 ноября 2019

Наш спокойный веб-сервис использует hazelcast 3.4.2. Мы используем IQueue для хранения объекта byte []. Один поток помещает объект в очередь, другой поток получает объект из очереди. Мы используем Jmeter, чтобы выполнить нагрузочный тест с 50 потоками. Когда объект небольшой (менее 10 КБ), он работает хорошо, время отклика приложения всегда меньше 50 мс, а процессор низок. Когда объект больше, например, 90 КБ, время отклика увеличится до 500 мс. Когда объект 250k, время отклика будет 2500 мс. В то же время процессор использует 60% -80%. Объем памяти составляет около 60% -80%.

Наш тестовый сервер - AWS m5.large: 2 ядра и 8G. Tomcat выделяет 6G памяти.

Мы пытаемся решить проблему следующими способами:

  1. Обновите Hazelcast до 3.12.
  2. Изменить счет резервного копирования на 0.

Эта проблема еще не устранена.

Вот монитор работоспособности Hazelcast с высокой задержкой в ​​prod, сервер prod равен 8Ядра и 16G памяти, tomcat выделяет 12G памяти:

2019-10-25 15: 11: 13.078] [INFO] [com.hazelcast.util.HealthMonitor] [ec1-12]: 5701 [dev] [3.4.2] процессоров = 8, Physical.memory.total = 14,7 ГБ, Physical.memory.free = 183,5 МБ, swap.space.total = 0, swap.space.free = 0, heap.memory.used = 1,8 Г, heap.memory.free = 8,8G, heap.memory.total = 10,7G, heap.memory.max = 10,7G, heap.memory.used / total = 17,31%, heap.memory.used / max = 17,31%,minor.gc.count = 129321, minor.gc.time = 2021051мс, major.gc.count = 1224, major.gc.time = 165825мс, load.process = 80,00%, load.system = 79,00%, load.systemAverage =469,00%, thread.count = 153, thread.peakCount = 198, event.q.size = 0, executor.q.async.size = 0, executor.q.client.size = 0, executor.q.query.size= 0, executor.q.scheduled.size = 0, executor.q.io.size = 0, executor.q.system.size = 0, executor.q.operation.size = 0, выполнитьtor.q.priorityOperation.size = 0, executor.q.response.size = 0, operations.remote.size = 8, operations.running.size = 2, proxy.count = 8, clientEndpoint.count = 0, соединение. active.count = 2, client.connection.count = 0, connection.count = 2

1 Ответ

1 голос
/ 05 ноября 2019

Эта проблема не связана с Hazelcast. То, что вы видите, является типичным случаем больших задержек сериализации / десериализации большого объекта.

В любой системе, в которой данные должны перемещаться из одной точки в другую, эти данные должны быть сериализованы в исходной точке, перемещаться по сети и могут быть десериализованы (не в вашем случае, это зависит от конфигурации) впункт назначения при отправке на хранение. При извлечении данные будут сериализованы (если ранее были десериализованы) в источнике, пройдены по сети и десериализованы в месте назначения. В вашем случае ваше приложение проводит большую часть своего времени в ser / des, о чем свидетельствует использование процессора.

Единственные способы уменьшить задержку: 1. использовать сериализацию Hazelcast, читайте здесь - https://docs.hazelcast.org/docs/3.12.4/manual/html-single/index.html#serialization 2. уменьшить размер объекта

...