Re: To thread or not to thread ?
JohnQ wrote:
"Carlos Moreno" <moreno_at_mochima_dot_com@mailinator.com> wrote in message
news:l2Vph.80252$9i3.367737@wagner.videotron.net...
JQP wrote:
[...] For example: GUI prog, use as many as
your heart desires; Database server: limit to the number of cores.
Why the principle applied to DB servers??
Someone emphasized the point that I should have said "limit the number of
RUNNING threads to the number of cores". As I think about that now, I
realize that it's impossible to have more threads running than the number of
cores (!). So, I think he meant that the number of ACTIVE threads (the ones
timeslicing the CPU) should be limited to the number of cores so as not to
incur the thread switching overhead. In light of that, I'll say that there
is no need to give the appearance of multiple DB transactions proceeding
along concurrently akin to indeed giving an analogous impression with GUIs.
I think the answer to your question is: because the goal is to get the most
work done in the least amount of time (maximize processing efficiency) and
that means minimizing the processing overhead (thread switching).
That's the goal for some uses of multi-threading, but it's
certainly not the only goal for data bases. A data base has to
be responsive---even if one client makes an expensive request
(in terms of CPU), the data base must respond rapidly to simple
requests from other clients.
Responsiveness is one of the most frequent reasons for using
multithreading. Responsiveness of a GUI, or responisiveness of
a server. (Data bases are just an example of a server.)
True that there is some
intensive work to be done, but I would expect that a portion of the
processing would be IO-bound (yes, DB servers should optimize as
much as possible the access to be made from memory instead of from
disk, but it can't be 100% diskless).
But it shouldn't be disk bound.
Part of it has to be, if you want to guarantee transactional
integrity.
That may mean you probably need a higher
performing storage subsystem. The goal is to service all requests in a
reasonable amount of time and avoid the following:
"Because of the high transaction volume we are encountering at this time,
your request could not be serviced. Please try again later. We regret any
and all inconvenience this may have caused and you should indeed demand
credit for the time the service was unavailable to you."
Exactly. And that means that my simple request must be able to
interrupt a long running complex request.
Saturating the disk subsystem is an exception (error) that must be handled
somehow (perhaps like above).
It's not a question of saturation. It's a question of letting
other requests advance while my request is blocked for disk
access. And any request which modifies data will block. (And
again, there's nothing special about data bases here. This is
true for just about any server.)
[...]
I would definitely expect a DB server --- if taking advantage of
multithreading at all --- to have more running threads than the
available cores.
Well in the scenario where the threads are in-progress transactions (not
long running ones), why would you want to switch between them and make small
progress toward completion of a bunch of them rather than taking a 1000 foot
view and seeing that more transactions are completed over the same period
time if the wasted CPU time used for switching threads is eliminated?
If all of the requests require a lot of CPU time, one could ask
the question. Typically, however, if I send a select request
over a single table, with a where clause based on the primary
index, I don't expect it to take minutes, just because someone
else is doing a complicated join over a number of tables, using
unindexed columns.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]