Modify

Opened 12 years ago

Closed 10 years ago

#10221 closed defect (fixed)

TimeoutError: Unable to get database connection within 20 seconds

Reported by: Ryan J Ollos Owned by: Michael Renzmann
Priority: normal Component: TracHacks
Severity: normal Keywords: monitoring
Cc: Steffen Hoffmann, osimons Trac Release: 0.12

Description (last modified by Ryan J Ollos)

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 (0)

Change History (11)

comment:1 Changed 12 years ago by Ryan J Ollos

Description: modified (diff)

comment:2 in reply to:  description ; Changed 12 years ago by Steffen Hoffmann

Keywords: monitoring added

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.

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

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.

comment:4 Changed 12 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:5 Changed 12 years ago by Ryan J Ollos

Cc: osimons added

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

comment:6 Changed 12 years ago 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... ;-)

comment:7 in reply to:  6 ; Changed 11 years ago by Ryan J Ollos

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.

comment:8 in reply to:  7 ; Changed 11 years ago by Steffen Hoffmann

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.

comment:9 in reply to:  8 Changed 11 years ago 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.

comment:10 Changed 11 years ago by Ryan J Ollos

Issue reported in t:#11016.

comment:11 Changed 10 years ago by Ryan J Ollos

Resolution: fixed
Status: newclosed

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
Set your email in Preferences
Action
as closed The owner will remain Michael Renzmann.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.