HI there!
I’m running 0.32.10, but I’m seeing this behaviour for quite long time.
When my Metabase instance reaches 15 open connections, it simply won’t run any query. No error will be thrown, nothing “wrong” happens - it just stays “doing science”, nothing at all show at the log. Not even automatic queries, like the ones metabase runs to use the autocomplete features will be run.
The multitude of connections is created when some user tries to update a really big dashboard, with some slow queries on it. The only way to effectively solve it is to kill all the running queries (and then kill them again, since metabase will relaunch all of them right after the first kill command).
I’m pretty sure it is not a database related issue because I can run more queries from my user without any trouble - it is just metabase which stops working for that given database (the others work normally).
Hi @lucas.lima
Metabase has a hardcoded limit of 15 connections per database (that includes the internal one for metadata). There are several issue discussing this, think this is one of the better ones. I’m linking to a work-around, since you can change the limit since 0.32.9 (I think) with i.e. c3p0.maxPoolSize=30.
Please read all the comments - you’ll add more load on your database if you up the limit. https://github.com/metabase/metabase/issues/8679#issuecomment-508560495
Thank you for the timely reply, as usual.
Now, that is a tough call to make, specially considering the someone reported a 200 connections limit being filled up, eventually. Gonna check it out with my Data Engineering / Data Ops team. Thanks, once again.
@lucas.lima
I think that’s something specific to AWS RDS. If you have more control over your database, then you can tell it to kill connections after X minutes. Metabase only handles 15 connections per database (a database counts as defined in Admin > Databases).
I don’t have long-running queries, so I have never really encountered this problem. When I have queries that takes more than 30 seconds, then I save the output to a view, so the end-user gets a response instantly from the view, but the data may be a few minutes old.
EDIT: The “safe” way to test this, would be to change the limit to let’s say 20 and just be prepared to go back to default, if you’re seeing any strange behavior.