Forum OpenACS Development: Re: Developer Support Database Statistics
I guess I explained it incorrectly. These aren't complex queries but its a script that processes thousands of records with short queries, so its just the total number of queries running. Thanks for the explanation. To debug or learn about the query statistics of such a script, a test mode which processes just a few rows makes more sense.
I will check out nsstats, that is helpful.
in terms of the locks, it makes no difference, whether a complex query or some maintenance script is run in a connection thread. The point is, when only one connection thread is active, then there are no locks from the developer support. If multiple connection threads are writing to the variables of the developer support, then locks must occur. Therefore, the locks you experienced depend on the current load caused by other users. If we would confine the developer-support to one connection thread, this would hurt busy sites much less than the current approach, where ds affects all threads.
I've now added the mutex statistics as well to the munin statistics of openacs.org . You can find there
- waiting time for locks (the biggest dent is a waiting time of 1.4ms during log-rolling)
- busy locks (currently 0.5 busy locks per second on average), and
- number of locks (currently 500 locks per second, peaks around 6.000 locks per second)
OpenAcs.org is quite an idle site, one other sites we see easily 10x these values (experiencing good performance). The values of munin are moving averages in 5 minute intervals. One can configure additional line for more mutexes in the munin scripts, when e.g. the lock statistics of nsstats indicate this. The munin graphics are useful to increase the understanding of the factors influencing the perceived performance, and to detect unusal behavior requiring attention.