Столкнувшись с проблемами, связанными с потоком, после проверки профилировщика потока в New Relic
98% sun.misc.Unsafe.park (логическое, длинное): родное 89%(java.lang.Object, long): 215 88% java.util.concurrent.locks.AbstractQueuedSynchronizer $ ConditionObject.awaitNanos (long): 2078 86% org.eclipse.jetty.util.BlockingArrayQueue.poll (long, java.util).concurrent.TimeUnit): 392 86% org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll (): 563 86% org.eclipse.jetty.util.thread.QueuedThreadPool.access. $ 800.thread.QueuedThreadPool): 48 86% org.eclipse.jetty.util.thread.QueuedThreadPool $ 2.run (): 626 86% java.lang.Thread.run (): 745
Снимок экрана также прилагается.
Функциональность построена с использованием Java-платформы Dropwizard для отправки сообщений через веб-сокеты с использованием Jedis (https://github.com/xetorthio/jedis/wiki/Getting-started). Отправка сообщений выполняется асинхронно с использованиемrunAsync ().
На самом деле у нас есть 2 стекаstack1 и stack2 имеют одинаковые конфигурации.Там, где stack1 работает очень хорошо при обслуживании как веб-запросов, так и этой функциональности при оборотах около 20k, но stack2 отнимает слишком много времени, которое специально используется для обслуживания только этой функциональности только при 5k оборотах в минуту.Пик числа потоков в стеке 2 увеличивается с 2000 на 3000, а в стеке 1 такой всплеск не наблюдается во время анализа.
Мы используем экземпляры AWS EC2 типа m4.large.Пожалуйста, помогите мне, если я что-то делаю неправильно.