It seems that with the amount of activity on our farm, the db is not coping all that well. Sometimes updating the task list takes 20-30 seconds (it comes and goes, sometimes its fast…). We currently have about 10k or so jobs in the queue
Did this just start happening with beta 9? We just discovered that we left some scheduling test code in where the slave would pull over the repository options from the database between every task, which we’ll be removing for beta 10.
Also, could you send us the database statistics? You can get them from the Monitor by selecting Help -> View Database Statistics.
Finally, what are the specs of your database machine (cpus, ram, etc)?
Thanks!
- Ryan
Stats attached.
32g of ram, 2.5ghz cpu, 8 cores, centOS 6.3, mongo 2.4.1
(sidenote, it probably helped us tweak the scheduling properties that the farm reacted so fast. Normally, how often are the repo properties queried?)
dbstats.txt (13 KB)
Thanks!
I took a look at the stats, and found this information:
- Lock Queue size = 0 (this means that nothing is backed up at this time)
- Lock ratio = 2.4% (this is how often mongodb has been in the locked state since it started, so this is good)
- Resident and mapped memory is 3GB and 6GB respectively (which is much less then your system has, so this is good)
- Page faults = 7077 (this seems like it might be a bit high)
Since your memory usage is relatively low, I’m not sure why those page faults would be occurring. I read that they happen in times of poor performance though, so maybe you get a burst of them during times when you see slow access.
How is the database responding now? Based on the stats, things should be pretty responsive. Maybe the next time things slow down, you could grab the database stats and post them again?
About every 10 minutes.
It actually crashed last night once, so i had to restart it. Maybe its healthier because of that?
Not sure what happened last night,… around 1am or so, i was trying to troubleshoot the pulse restarting / crashing problem, and figured i would do a clean pulse reinstall just in case. As soon as that finished, the mongo database crashed.
Took me about 10-15 minutes to figure out that i didn’t screw up the pulse install, but its actually mongo having gone missing (all i saw was database connection errors in the pulse log, so first i thought maybe the latest installer has done something bad). I reinstalled one of pulse’s older builds, the error was still there, then noticed mongo being down. Restarted that, then reinstalled the latest beta(9) again to see if it kills mongo again, but it did not.
So maybe it was just a lucky coincidence that i was actually looking at the logs actively when the database went down, and was there to restart it, or it was caused by the pulse reinstall (which i doubt)… hard to tell. I still have to fish through the logs but last night i couldnt see anything about the crash.
If you are experiencing Access database performance issue, then you must have to look into these problem generating sections:
• Poor Access database configuration.
• Native use of database triggers.
• Poor use of indexes.
• Database deadlocks situations due to transaction boundaries which overlaps
• Scalability problems due to Access patterns.
Apart from this, there are many more section in which you have to look into for easy troubleshooting of slow running Access database** performance issue.
Other than this you can check out this beautifully presented infographic.
Once you troubleshoot all the issues mentioned above. Then this will automatically fix your slow working Access database.