score:2

Accepted answer

when using database.forconfig a different value for the queue size can be provided.

slick documentation

score:9

1000 queued tasks seems like a lot to me. clearly, slick is using an executor with a fixed size queue (1000 elements), and you're running into that limit because tasks are not being retired quickly enough.

the most obvious cause is sql execution times. if you can get your sql execution times down, you'll buy yourself a lot of headroom in the queue.

typically, this would be done database-side by checking query execution plans, and depending on the database, asking the database what the long running queries are.

on the hikaricp side, you might want to enable dropwizard metrics (not sure how to do that through slick, tho) and enable a dropwizard log reporter to log pool statistics every 10 seconds or so.

probably the most interesting metric there would be usage, as that will show you how long connections are out of the pool between getconnection() and close(). as you tune your database and/or queries, you want to see that number start dropping.

one crucial point is, if the database cannot keep up with your application load, increasing the slick queue from 1000 to 5000 (or even 10000) will buy you nothing except a small amount of time before it reaches that limit. you have to find the source of the performance bottleneck and eliminate it, such that queues are retired faster than your application generates them (excepting temporal spikes of course).


Related Query

More Query from same tag