Время ожидания записи сеанса в Apache Ignite - PullRequest
0 голосов
/ 28 апреля 2020

Мы выполняем нагрузочный тест на Apache Ignite.

У нас есть 1 сервер БД и 1 сервер приложений Tomcat.

Обе машины имеют эту настройку.

CPU Intel I7
Speed   2.6Ghz
Cores   4
Ram 16GB
Disk 500GB

Конфигурация ->

App server Java Heap -> Xms512m, Xmx3072m.
DB server Java Heap -> Xms512m, Xmx3072m.
DB server persistence -> true
DB server Offheap Max size -> 3072m.
Write throttling enabled.
Client failure detection timeout set to 10000ms
Failure detection timeout set to 30000ms
Query thread pool size is the default -> 8

Сценарий ->

Через сервер приложений tomcat я запустил 500 потоков, которые запускают бизнес-логи c для установки и получения данных из Ignite. , В коде существует семафорная блокировка для доступа к кешу, и потоки обычно находятся в заблокированном состоянии, поскольку другие потоки используют ресурсы. После запуска, скажем, в течение 3-4 часов, сервер приложений выдал предупреждение, упомянутое ниже.

"org.apache.ignite.logger.java.JavaLogger" "warning" "WARNING" "" "294" "Communication SPI session write timed out (consider increasing 'socketWriteTimeout' configuration property) [remoteAddr=xxxxx/xxxxx:47100, writeTimeout=2000]" "" "" "" "" "" "" "" "" "" "" "" "" "" "ROOT" "{""service"":""xxxx"",""logger_name"":""org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi""}"

Я также видел довольно много распечаток «Возможно, слишком длинная JVM» до того, как этот отпечаток показывал около 500 мс до Задержка 1000 мс.

После того, как было выполнено исключение, через несколько минут клиент отключился и запросил эту ошибку ->

org.apache.ignite.internal.IgniteClientDisconnectedCheckedException: Query was canceled, client node disconnected.

Пока все работало нормально, я включил JProfiler просто для Посмотрите, как он работает в JVM сервера приложений, и я вижу, что многие потоки находятся в состоянии «заблокировано». И поскольку это 4-ядерный компьютер, я вижу, что одновременно может выполняться не более 12-15 потоков сервера приложений (с использованием логических ядер). А затем выйдите из профилировщика и дайте ему поработать в течение 2-3 часов, пока не произойдет исключение.

Хотя в реальном времени мы не будем порождать столько потоков, а в работе у нас будет 100 ядер. на серверах для нас важно понять, как мы можем настроить развертывание, которое будет масштабироваться для удовлетворения потребности в создании множества потоков.

Может кто-нибудь объяснить, пожалуйста?

1 Ответ

0 голосов
/ 28 апреля 2020

Похоже на длинную G C, в результате чего клиентский узел сегментируется. Какое самое длинное сообщение «Возможно, слишком длинная пауза JVM»? Вы пытались увеличить failureDetectionTimeout? Уменьшение размера кучи клиентских узлов?

...