Knex: Timeout acquiring a connection

[rjeevaram]

⚠️ Please verify that this question has NOT been raised before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

📝 Describe your problem

I've been facing the below error in Uptimekuma Monitor recently. Has anyone faced this issue and any solution?

Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?

📝 Error Message(s) or Log

Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?

🐻 Uptime-Kuma Version

1.23.11

💻 Operating System and Arch

Running as K8s pods in debian 11 Node

🌐 Browser

Chrome 122.0.6261.94

🖥️ Deployment Environment

• Runtime:
• Database:
• Filesystem used to store the database on:
• number of monitors:

[CommanderStorm]

Please fill out the Deployment Environment to help us debug this.
In addition, what retention have you configured?

TL;DR:
In v1, reducing either retention/ping-rate/.. or moving to a faster storage solution is the only option to get around this problem.
In v2, we have likely resolved this problem. See #4500 for further details of what needs to happen before we can release this version.

[CommanderStorm]

I am going to close this as resolved by v2.0 as I don't see evidence to the contrary.

TL;DR:
In v1, reducing either retention/ping-rate/.. or moving to a faster storage solution is the only option to get around this problem.
In v2, we have likely resolved this problem. See #4500 for further details of what needs to happen before we can release this version.

[thebiblelover7]

@CommanderStorm Is the only option to wait for v2? I've set my activity history to 7 days, have only 12 monitors, I've wiped out the database and I still have the same issues....

[CommanderStorm]

@thebiblelover7 Your issue seems somewhat strange.

• What storage are you running? (nfs, emmc, sd-card?) => 12 monitors with 7 days is way lower than reported by anybody..
• Could you have a look if this button works? (Was your db created before v1.10?)
  

[thebiblelover7]

@CommanderStorm I'm running it on an Oracle Instance, so I don't know what storage they use.... But with other servers I've run on their instances, they seem to be running totally fine.

I've run Shrink Database multiple times even though I believe my db was created after v1.10

It has definitely been strange. Now I can't believe whenever I get spammed with 12 notifications saying all my services are down because of this issue....

[CommanderStorm]

v2 will likely not solve your particular deployment issue. If you have suuuch slow IO, there is not much that can be done for you..
Maybe Oracle does have a plan or configuration where you get more than a few disk reads a second (Your IO must be sloooooow to run into this that early)..

Maybe the machine you are running on has defective IO.. (contact support if benchmarks differ too much..)
Really can't tell without further debugging on your end.. (IO-benchmarks, lscpu, a link to oracles page for your instance-type)

[thebiblelover7]

Well, @CommanderStorm , I recreated the instance, set the IO as fast as I could, and used ubuntu minimal instead of Oracle Linux... we'll see how it goes now. So far (last hour) it's working well.