On Wed, Nov 28, 2007 at 10:33:08AM -0800, Trevor Talbot wrote: > On 11/28/07, Magnus Hagander <magnus@xxxxxxxxxxxx> wrote: > > Trevor Talbot wrote: > > > On 11/28/07, Magnus Hagander <magnus@xxxxxxxxxxxx> 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. There are actually two different ways to run SQL Server. Either it runs with operating system threadpools (the same way that we deal with backend exits in 8.3), which is IIRC the default. Or it runs with Fibers which are also an OS feature, but they're scheduled by the application. > > > 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. Ok, then I understand what you're saying :-) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
