1000 задач в очереди мне кажется много. Очевидно, что slick использует исполнителя с очередью фиксированного размера (1000 элементов), и вы упираетесь в этот предел, потому что задачи удаляются недостаточно быстро.
Наиболее очевидная причина — время выполнения SQL. Если вы сможете сократить время выполнения SQL, вы купите себе много места в очереди.
Как правило, это делается на стороне базы данных, проверяя планы выполнения запросов и, в зависимости от базы данных, запрашивая у базы данных, каковы длительные запросы.
На стороне HikariCP вы можете включить метрики DropWizard (не знаете, как сделайте это с помощью slick) и включите DropWizard log reporter для регистрации статистики пула каждые 10 секунд или около того.
Вероятно, наиболее интересной метрикой будет использование, поскольку она покажет вам, как долго соединения находятся вне пула между getConnection() и close(). Когда вы настраиваете свою базу данных и/или запросы, вы хотите, чтобы это число начало снижаться.
Одним из важных моментов является то, что если база данных не справляется с нагрузкой вашего приложения, увеличение гладкой очереди с 1000 до 5000 (или даже 10000) не даст вам ничего, кроме небольшого количества времени, прежде чем она достигнет этого предела. Вы должны найти источник узкого места производительности и устранить его, чтобы очереди удалялись быстрее, чем ваше приложение их генерирует (конечно, за исключением временных всплесков).
person
brettw
schedule
28.07.2015
