Modify

Opened 2 years ago

Closed 11 months ago

#10221 closed defect (fixed)

TimeoutError: Unable to get database connection within 20 seconds

Reported by: rjollos Owned by: 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 (0)

Change History (11)

comment:1 Changed 2 years ago by rjollos

  • Description modified (diff)

comment:2 in reply to: ↑ description ; follow-up: Changed 2 years ago by hasienda

  • 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 2 years ago 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.

comment:4 Changed 2 years ago 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).

comment:5 Changed 2 years ago by rjollos

  • Cc osimons added

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

comment:6 follow-up: Changed 2 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 ; follow-up: Changed 2 years ago 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.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 2 years ago 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.

comment:9 in reply to: ↑ 8 Changed 2 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 23 months ago by rjollos

Issue reported in t:#11016.

comment:11 Changed 11 months ago by rjollos

  • Resolution set to fixed
  • Status changed from new to 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.

Add Comment

Modify Ticket

Action
as closed The owner will remain otaku42.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.