2016-09-16 1 views
7

Я пытаюсь понять, как работает Slick-Hikari, я прочитал много документации, но у меня есть прецедент, поведение которого я не понимаю.Slick with Hikari не использует больше соединений при необходимости

Я использую Slick 3 с Hikari с конфигурацией по умолчанию. У меня уже есть производственное приложение с ~ 1000 пользователями, подключенными одновременно. Мое приложение работает с веб-сайтами, и когда я развертываю новую версию, все клиенты повторно подключаются. (Я знаю, что это не лучший способ справиться с развертыванием, но на данный момент у меня нет кластеризации.) Когда все эти пользователи снова подключаются, все они начинают делать запросы, чтобы получить свое состояние пользователя (эффект собачьей кучи). Когда это произойдет, скользкие начинает бросать много ошибок, как:

java.util.concurrent.RejectedExecutionException: Task [email protected] rejected from [email protected][Running, pool size = 20, active threads = 20, queued tasks = 1000, completed tasks = 23740] 

То, что я думаю, что это происходит, что пятно очередь для ожидающих запросов переполнена, поскольку он не может обрабатывать все клиентов, запрашивающих информацию из базы данных. Но если я вижу, что показатели Dropwizard дает мне, я вижу следующее:

Example of Observed Dropwizard Metrics

Рядом 16:45 мы себе в развертывании. До тех пор, пока старый экземпляр не будет завершен, мы увидим, что количество соединений составляет от 20 до 40. Я думаю, это нормально, учитывая, как выполняется процесс развертывания.

Но если очередь запросов Slick заполнена из-за эффекта собачьей кучи, почему она не использует более 3-5 соединений, если имеется 20 подключений? База данных работает очень хорошо, поэтому я думаю, что узкое место находится в Slick.

Есть ли у вас какие-либо рекомендации по улучшению этого процесса развертывания? Сейчас у меня всего 1000 пользователей, но за несколько недель у меня будет намного больше.

+0

Возможно, имеется ниспадающий сбой, показывающий, где будут помогать все эти 20 якобы «активных» потоков в ThreadPoolExecutor? Они заблокированы на HikariCP? Они заблокированы чем-то еще? Кроме того, какая версия (точно) Slick и HikariCP? – brettw

+0

Помогает ли это http://stackoverflow.com/questions/29897003/slick-3-0-rc3-fails-with-java-util-concurrent-rejectedexecutionexception? – brettw

+0

Какая версия Slick и HikariCP? Я знаю, что Slick внес некоторые изменения, чтобы попытаться увеличить параллелизм за последние несколько месяцев ... – brettw

ответ

0

Основываясь на исключенном исключении, я думаю, что многие слабые действия были представлены одновременно, что превысило размер по умолчанию (1000) очереди, встроенной в slick.

Так что я думаю, вы должны:

  1. увеличить размер очереди (Queuesize) провести более необработанное действие.
  2. увеличить количество потоков (numThreads) в slick для обработки дополнительных действий одновременно. You can get more tips here
Смежные вопросы