Ticket #10221 (new defect)

Opened 10 months ago

Last modified 4 months ago

TimeoutError: Unable to get database connection within 20 seconds

Reported by: rjollos Assigned to: otaku42
Priority: normal Component: TracHacks
Severity: normal Keywords: monitoring
Cc: hasienda, osimons Trac Release: 0.12

Description (Last modified by rjollos)

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.

More info is available via the private dashboard. If anyone want to receive up/down notifications and access to the private dashboard, let me know and I'll add you to the account.

Attachments

Change History

08/02/12 22:56:58 changed by rjollos

  • description changed.

(in reply to: ↑ description ; follow-up: ↓ 3 ) 08/03/12 07:06:12 changed by hasienda

  • keywords set to monitoring.

Replying to rjollos:

[...] If anyone want to receive up/down notifications and access to the private dashboard, let me know and I'll add you to the account.

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.

(in reply to: ↑ 2 ) 08/03/12 10:00:36 changed by rjollos

Replying to hasienda:

Add me to the list.

I've added you.

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.

08/09/12 20:35:00 changed by rjollos

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).

09/24/12 19:43:26 changed by rjollos

  • cc changed from hasienda to hasienda, osimons.

A thread was raised on the mailing list about this issue.

(follow-up: ↓ 7 ) 09/26/12 02:01:51 changed by osimons

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... ;-)

(in reply to: ↑ 6 ; follow-up: ↓ 8 ) 10/01/12 20:09:57 changed by rjollos

Replying to osimons:

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.

(in reply to: ↑ 7 ; follow-up: ↓ 9 ) 10/01/12 21:03:34 changed by hasienda

Replying to rjollos:

Replying to osimons:

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.

(in reply to: ↑ 8 ) 10/01/12 21:07:12 changed by falkb

Replying to hasienda:

Replying to rjollos:

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.

01/13/13 01:53:34 changed by rjollos

Issue reported in t:#11016.

Add/Change #10221 (TimeoutError: Unable to get database connection within 20 seconds)




Change Properties
Action