Opened 5 years ago

Closed 3 years ago

TimeoutError: Unable to get database connection within 20 seconds

Reported by: Owned by: Ryan J Ollos Michael Renzmann normal TracHacks normal monitoring Steffen Hoffmann, Odd Simon Simonsen 0.12

Seems to be a fairly regular occurrence. I've setup a monitoring site that checks trac-hacks every 1 minute and sends a notification if the site is down for more than 5 minutes (down = WikiStart doesn't load in < 30 seconds).

You can view the monitoring stats here: http://stats.pingdom.com/9hmtun56fv5v/618204.

comment:1 Changed 5 years ago by Ryan J Ollos

Description: modified (diff)

comment:2 in reply to:  description ; follow-up:  3 Changed 5 years ago by Steffen Hoffmann

Add me to the list, please. But you may want to change the test, because especially GETting WikiStart should be rather resource-sensitive due to the underlying queries, and another generic page like i.e. TracWiki should do as well. Or was it by intention? After all the front page is the most important entry point to the site, sure.

comment:3 in reply to:  2 Changed 5 years ago by Ryan J Ollos

But you may want to change the test, because especially GETting WikiStart should be rather resource-sensitive due to the underlying queries, and another generic page like i.e. TracWiki should do as well. Or was it by intention? After all the front page is the most important entry point to the site, sure.

Good point. I've changed the check to point to TracHacksPlugin.

comment:4 Changed 5 years ago by Ryan J Ollos

The response time was 10+ ms for WikiStart, and the graph shows that its been consistently ~2 ms for the TracHacksPlugin page. I've received very few down notifications since changing the monitoring to the TracHacksPlugin page.

What I'm most interested in, is how my experience in receiving database timeout errors maps to the response time and up/down time. The next time I see a long and extended slowdown in my interactions with trac-hacks, along with database timeout errors, I'll compare my experience to the data, and if they don't match, might switch the monitoring back to WikiStart for some extended time period to see how that data compares with actual experience.

It would be nice to monitor both WikiStart and TracHacksPlugin pages for some time and compare the data. Monitoring more than one site requires a paid account, but I think I can add two sites to the paid account at my workplace without going over the limit for our current plan, so I may be able to monitor both via that account for a time period (e.g. 1 month).

comment:6 follow-up:  7 Changed 5 years ago by Odd Simon Simonsen

Well, the problem is solved. Only in a much more recent version of Trac than what is currently in use here. Suggesting 'worksforme' with upgrade as recommended solution... ;-)

comment:7 in reply to:  6 ; follow-up:  8 Changed 5 years ago by Ryan J Ollos

Well, the problem is solved.

Just curious, did you find a specific ticket, or some evidence via your debugging that led you to know it is an issue with Trac and not an installation issue?

Only in a much more recent version of Trac than what is currently in use here. Suggesting 'worksforme' with upgrade as recommended solution... ;-)

Thank you for your response and efforts to move this along. I'm working my way down my current task list to a point when I hope to have enough time to mobilize the effort to move the upgrade along. I'd be thrilled if someone beat me to that ;)

Your suggestions in a recent email to upgrade Trac on the current server in the db-container seemed reasonable to me. I was stuck on the idea that we couldn't do much before the new server space was available, but the upgrade-then-move approach seems reasonable.

comment:8 in reply to:  7 ; follow-up:  9 Changed 5 years ago by Steffen Hoffmann

Well, the problem is solved.

Just curious, did you find a specific ticket, or some evidence via your debugging that led you to know it is an issue with Trac and not an installation issue?

See this too, seems like t:#9111 is a suitable candiate, right?

Only in a much more recent version of Trac than what is currently in use here. Suggesting 'worksforme' with upgrade as recommended solution... ;-)

...

Your suggestions in a recent email to upgrade Trac on the current server in the db-container seemed reasonable to me. I was stuck on the idea that we couldn't do much before the new server space was available, but the upgrade-then-move approach seems reasonable.

Yes, let's to it that way.

comment:9 in reply to:  8 Changed 5 years ago by falkb

Your suggestions in a recent email to upgrade Trac on the current server in the db-container seemed reasonable to me. I was stuck on the idea that we couldn't do much before the new server space was available, but the upgrade-then-move approach seems reasonable.

Yes, let's to it that way.

Did you think about the opportunity to install TH in a virtual machine? This way one could easily move the whole system to another hardware or even new maintainer.

comment:10 Changed 4 years ago by Ryan J Ollos

Issue reported in t:#11016.

comment:11 Changed 3 years ago by Ryan J Ollos

Resolution: → fixed new → closed

I believe the issue is resolved since the upgrade. The site is still relatively slow, but we are still aiming to move it to new hosting eventually.

Modify Ticket

Change Properties