On 11/28/07, Magnus Hagander <magnus@hagander.net> wrote:
> Trevor Talbot wrote:
> > On 11/28/07, Magnus Hagander <magnus@hagander.net> wrote:
> >> There is at least one other bottleneck, probably more than one. Context
> >> switching between processes is a lot more expensive than on Unix (given
> >> that win32 is optimized towards context switching between threads). NTFS
> >> isn't optimized for having 100+ processes reading and writing to the
> >> same file. Probably others..
> > I'd be interested to know what this info is based on. The only
> > fundamental difference between a process and a thread context switch
> > is VM mapping (extra TLB flush, possible pagetable mapping tweaks).
> Generally, lots of references I've seen around the net and elsewhere. If
> I'm not mistaken, the use of threads over processes was listed as one of
> the main reasons why SQL Server got such good performance on Windows
> compared to it's competitors. But I don't have my Inside SQL Server
> around to check for an actual reference.
Well, yes, in general using multiple threads instead of multiple
processes is going to be a gain on any common OS for several reasons,
but context switching is a very minor part of that. Threads let you
share state much more efficiently than processes do, and in complex
servers of this type there tends to be a lot to be shared.
SQL Server is somewhat unique in that it doesn't simply throw threads
at the problem; it has a small pool and uses its own internal task
scheduler for actual SQL work. There's no OS thread per user or
anything. Think continuations or pure userspace threading. That design
also lets it reduce context switches in general.
> > I mean, I can understand NT having bottlenecks in various areas
> > compared to Unix, but this "threads are specially optimized" thing is
> > seeming a bit overblown. Just how often do you see threads from a
> > single process get contiguous access to the CPU?
>
> On a CPU loaded SQL server, fairly often I'd say. But certainly not always.
I meant as a design point for a general-purpose OS. If you consider
how Windows does GUIs, ignoring the expense of process context
switching would be fatal, since it forces so much app involvement in
window painting. Having a system dedicated to a single process with
multiple threads running full-bore is not particularly common in this
sense.
