At 10:42 10/01/00 +0100, Andreas Vierengel wrote:
>I have managed to setup a load-balanced method to distribute the number of
>db-connections initiated from the perl-skripts, so that every db has
>same number of running threads...
>My problem is the load of the machines...
>I can't set the running threads in relation to the CPU-load. Some sessions do
>queries which are not complicated and therefore very fast, and other do
>which are more cpu-ressource intensive...
>Almost all queries have execution times of < 1s ( measured on a system
>If I could manage the machines not to go beyond 3.00 load it would really
>me a lot !
Why not allocate jobs on the basis of current load instead of number of
running threads? Presumably your scheduler could then make an approriate
response to the user if no server was available with a low enough load.
If have lots of *VERY* trivial queries and a few *VERY* *VERY* complicated
queries which on their own would drive the load up over 3.00, and your
objective is to weed out the complicated queries, then this would not solve
the problem. It is possible to cost queries before executing them using the
EXPLAIN command (see the manual for more details) however it does require
some human intelligence to make sense of the output. Whether it would be
possible to translate this into a 'cost'....? I suppose you could attempt
an empirical solution by looking at queries which have been run, seeing if
you can correlate this with the number of lines of output from EXPLAIN, or
the number of occurrences of 'ref'.
Just a thot.