Opened 12 years ago
Closed 11 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 )
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
| Description: | modified (diff) |
|---|
comment:2 follow-up: 3 Changed 12 years ago by
| Keywords: | monitoring added |
|---|
comment:3 Changed 12 years ago by
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
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
| Cc: | osimons added |
|---|
A thread was raised on the mailing list about this issue.
comment:6 follow-up: 7 Changed 12 years ago by
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 follow-up: 8 Changed 12 years ago by
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 follow-up: 9 Changed 12 years ago by
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 Changed 12 years ago by
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:11 Changed 11 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | 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.
Replying to rjollos:
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.