Re: Lies, Damn Lies and Statistics...

On Jan 27, 9:37 am, Ian Michael Gumby <im_gu...@xxxxxxxxxxx> wrote:
Not to bust Liam's bubble,

But what happens when you have two different threads from the same
parent trying to run at the same time on different CPUs?

Me thinks that there's more spin and double talk that meets the eye?

I wonder when there will be a processor affinity switch added to the
OSs if there isn't one already.

Also whenever you create a thread, any thread, the OS has some level
of schedule over it. ;-)

But Hey What do I know?
I've never looked at the source code of either IDS or DB2. ;-)

-G

On Jan 26, 9:05 am, lfin...@xxxxxxxxxx wrote:

On Jan 25, 7:24 pm, "da...@xxxxxxxxxxxxx" <da...@xxxxxxxxxxxxx> wrote:

On 24 Jan, 22:17, Mark Townsend <markbtowns...@xxxxxxxxxxxxx> wrote:

Where do you think DB2 got its multi-threaded server from?
DB2 for LUW was multi-threaded on Windows since inception
(DB2 V5.1 I think).
All that was done in DB2 9.5 was to extend the concept to Unix/Linux.

You shouldn't talk about things you know nothing about.

And I wouldn't really call it multi-threaded. Rather just a bunch of
processes now run as threads in a single process, with a single address
space. The diagram athttp://www.ibm.com/developerworks/db2/library/techarticle/dm-0807khar...
shows this quite well

I have some questions

1 Can network communicating threads run in a seperate process from
the rest of the engine? A process that can block inside
an OS call. Informix can with NETTYPE NET and under certain
workloads this gives better performance.

2. Can network communicating threads run in the db2sync process? This
means the threads have to use network calls that
do not block. Informix can with NETTYPE CPU and under certain
workloads this gives better performance due to lower
context switching.

3. Can you have multiple db2sync processes? Otherwise how does db2 use>1 cpu? If so are session threads (EDUs) able to

migrate between db2sync processes? I believe Sybase statically
binds sessons to engines hence if the engine is busy
running the thread for one engine then other threads on that engine
cannot migrate to idle engines! Being able to migrate
threads between engines was one of Informixs advantages over other
multi-thread engines.

Biggest advantage is that shared memory management becomes easier (for
the developers, mainly).

Nice to see DB2 catching up with Informix. Pity DB2 cannot
dynamically add shared memory segments on Linux.

Not at all like what Informix did when they rewrote the engine from 5 to
6 (7) to become multi-threaded. Which, BTW, solved on set of issues, but
introduced a completely different set.

Hi David,

DB2's threading model is different than IDS. With DB2, each thread
maps directly to a kernel thread, so each can be individually
scheduled by the OS. So, if any one DB2 thread is blocked, the OS is
free to schedule any other DB2 thread on that same processor, or any
other processor. That also means that as one CPU gets too overloaded,
the OS is free to re-schedule any DB2 threads on other, less loaded,
CPUs, as it sees fit.

One of the main benefits with going threaded on UNIX/Linux is the
simplification to our memory model, both internally (for development),
but more importantly for customers, in terms of ease of
administration. The following sections in the docs highlight these
changes:https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic...
The following link gives a little more detail on how the memory
parameters and the self-tuning memory manager interact with each
other:https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic...

For your last question, DB2 does in fact allocate new shared memory
segments during runtime. If you want to see this in practice, just
activate your database, then dynamically create a new bufferpool (or
dynamically increase your locklist, shared sort heap, etc). In 9.5,
this operation should always succeed, and if you issue 'db2pd -db
dbname -memsets', you should see that there are multiple shared memory
segments now associated with your database. If you tried this same
exercise in DB2 9 or earlier, this same operation would have likely
failed, since we could not dynamically allocate new shared memory
segments during runtime.

Cheers,
Liam.

Why would it matter if the OS tries to schedule two different threads
at the same time on different CPUs? Why would this be any different
than if the OS tried to schedule two different processes from the same
parent on different CPUs?

When DB2 creates threads, we specify the 1:1 model, where each thread
maps to it's own kernel thread. So, when scheduling, each kernel
thread is seen as a distinct schedulable entity, just as if it was a
separate process. The only difference is that depending on the
platform, the OS can usually context switch faster between two kernel
threads within the same process. Going to a threaded model does mean
though that there will now be OS kernel contention for some OS APIs
(i.e. any API that needs a lock on the process-wide address space, for
instance, allocating a new shared memory segment), so as part of our
normal performance validation work, the development team worked
through these new synchronization bottlenecks and either reduced them
to acceptable levels (i.e. performance similar to previous non-
threaded architecture), or redesigned DB2 code to avoid the
bottleneck.

For your other comment (processor affinity), pretty much all platforms
support this. If you're not careful though, just pinning a particular
process or kernel thread to a processor can hurt performance - the OS
cannot do any load balancing (and I doubt any application would be
able to do a better job at load balancing than the OS, especially when
there are other applications running on the box). An area that is
much more interesting is memory access costs relative to particular
CPUs - particularly in large AIX machines, which are becoming more and
more NUMA like (Non-Uniform Memory Architecture). Even smaller AMD64
boxes have NUMA characteristics (can't recall offhand if each core has
it's own memory controller, or if each chip has it's own, but it's
cheaper to access memory controlled by the current CPU's memory
controller than some other CPU's memory controller). Trying to solve
this in large software systems that make extensive use of shared
memory is very difficult (i.e. where do you try to locate a memory
page, for example, a page in the bufferpool, when you don't know which
CPUs may need access to that page?). Ever since DB2 v8 (before DB2
was threaded), we've tried to optimize for this type of system - if
you look up the documentation on the DB2_RESOURCE_POLICY registry
variable, you'll see what's available in this area for DB2. And in
each release (included 9.5 - the threaded engine), this support is
expanded in some way.

You can try to bust my bubble all you want, but since I have looked at
DB2 source code (I'm a senior DB2 kernel developer), and was a key
member of the team that implemented the threaded engine work, I'll
just blow it back up again :-)

Cheers,
Liam.
.

Relevant Pages

  • Re: Lies, Damn Lies and Statistics...
    ... at the same time on different CPUs? ... One issue is how does the stack get handled by multiple cpus. ... then two cpus try to attach to the same shared memory segment at the ... DB2 manages it's own stack memory. ...
    (comp.databases.informix)
  • Re: 2nd CPU on a Sun Blade 2000 problem
    ... memory) and left the original in the '0' slot? ... will only find in a Sun Fire 280R (uses the same CPUs and system board, ... but is a rack mount server, and the RSC card allows "LOM" (Lights Out ... framebuffer slot -- and there is no way to use a UPA framebuffer in the ...
    (comp.sys.sun.hardware)
  • Re: Best FPGA for floating point performance
    ... > the problem with highly threaded cpus is that they are not very good ... SW performance today as well as the cpus memory systems that don't like ... also FPGA P/R have no locality at all. ... Sparc in its Niagara form will serve their needs better than any x86, ...
    (comp.arch.fpga)
  • Re: Intel details future Larrabee graphics chip
    ... for dinky little SMP systems of 4-8 cores. ... Why multi-thread *anything* when hundreds or thousands of CPUs are ... video CPUs using fancy memory and generics doing the grunt work. ... Duo, and never get trojans, memory leaks, any of that. ...
    (sci.electronics.design)
  • Re: what is the meaning of registers,internal memory?
    ... Unlike RAM, these little scratch pads as I mentioned are tucked away ... RAM = Random Access Memory, ... number of CPUs on a memory bus, and eliminates the bottlenecks with many ... NUMA systems are not clusters however, ...
    (comp.lang.asm.x86)
Loading