Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Thread Thrashing under Win32

Re: Thread Thrashing under Win32

From: EscVector <>
Date: Sat, 09 Jun 2007 04:32:22 -0000
Message-ID: <>

On Jun 8, 8:07 pm, joel garry <> wrote:
> On Jun 8, 11:28 am, BD <> wrote:
> > I'm working with a developer to deploy Oracle db 64-bit under
> > Win64. Custom front-end app.
> > He's asking a question which seems relevant to Oracle architecture,
> > but I find no mention of this term anywhere on Metalink.
> > Basically, he's concerned that the processes parameter in the db
> > (which has been set moderately high for initial testing) will result
> > in the same number of threads being created in the Oracle Windows
> > process - and that this high number of threads will result in 'thread
> > thrashing' (a term I wasn't familiar with until today), which will
> > limit scalability.
> > I gather that 'thread thrashing' is a situation where a process slows
> > down because of excessive context switching between the threads inside
> > the process.
> > My response is pretty pragmatic - let's not worry about that problem
> > unless we have specific reason to worry about it, or unless we see
> > evidence of a problem in the Dev environment.
> > Meanwhile, I'm trying to identify a precedent wherein someone has
> > actually *seen* performance issues related to context switching of
> > this kind in a Win32/Win64 deployment.
> > Thus far I'm coming up dry.
> > Does anyone know of any 'guidelines' Oracle provides which would limit
> > the number of processes (and therefore threads in the OS process)
> > because of a concern like this? I've tried looking for 'thread
> > thrashing' on Metalink, and predictably get nothing at all - 'Context
> > Switching' isn't leading me to anything of use either.
> > I'd like to tell this gent that thread thrashing of this kind is not a
> > concern - but I'd prefer to have some kind of architectural provision
> > in front of me, to back that up... plus, assuming this kind of
> > excessive context switching within the Win32 process is even a
> > possibility, I'm not clear how you'd identify that it's occurring...
> > Thanks for any suggestions...
> "With a thread, multiple entities can use the same process, thus
> avoiding context switches."
> White paper that notes threads switch context faster than processes
> and share more data structures:
> My speculation is some java or mysql or perl thread-thrashing has
> morphed into a windows myth. I'm anti-windows, but even more anti-
> myth.
> jg
> --
> is bogus.
> Windows tuning:

Note: this is the second time I've tried to post this, so if it appears twice,.. it appears twice.

Great links, but the wording in the first link slightly muddles Oracle Processes, Windows Threads, and Windows Process, by not explicitly defining each as they were being discussed.

The Oracle init parameter "processes" directly equates to Windows threads running within the Windows Oracle.exe process.

There is one Oracle.exe Windows process per running instance. This Windows process has at least as many threads as oracle processes as noted by querying v$process.

Wikipedia has a good thread/process comparison.

To demonstrate:

Open task manager and notice the tab named "Processes". These are Windows processes. The listed Processes have many components, threads being one of them.

A thread is the smallest executable or transactional unit within a Windows process.
Windows processes have many threads.

As example, you can start and stop processes, but you can't start and stop threads as they are part of the Windows process and controlled internally.

Based on examples below:
1. How many processes were configured in test? 2. How many concurrent dedicated connections are expected?

The Oracle process init parameter directly equates with threads in that, Oracle.exe is the Windows process and is listed once for every running instance. Oracle then equates threads with oracle processes for every dedicated connection.

No connections in database:
C:\work\admin\sysinternals>pslist |grep "oracle"

Name                Pid Pri Thd  Hnd   Priv        CPU Time    Elapsed
oracle             1128   8  26  532 655236     0:00:54.125

One Connection:
C:\work\admin\sysinternals>pslist |grep "oracle" oracle 1128 8 27 547 656420 0:00:54.156 0:40:15.531

10 Connections:
for /L %i in (1,1,10) do start sqlplus scott/tiger

C:\work\admin\sysinternals>pslist |grep "oracle" oracle 1128 8 37 705 669912 0:00:55.609 1:02:51.796

150 Connections:
for /L %i in (1,1,150) do start sqlplus scott/tiger C:\work\admin\sysinternals>pslist |grep "oracle" oracle 1128 8 153 2589 822304 0:01:00.890 1:08:22.171

ORA-00020: maximum number of processes (%s) exceeded

Using an existing connection we see the following:

Connected to:
Oracle Database 10g Enterprise Edition Release - Production With the Partitioning, OLAP and Data Mining options

23:43:50 SCOTT_at_BJORK4> select count(*) from v$session;



Elapsed: 00:00:00.00
23:47:49 SCOTT_at_BJORK4> select count(*) from v$process;



Elapsed: 00:00:00.00
23:47:55 SCOTT_at_BJORK4> show parameter processes

NAME                                |TYPE       |VALUE
processes                           |integer    |150

23:43:51 SCOTT_at_BJORK4> show parameter sessions
NAME                                |TYPE       |VALUE
sessions                            |integer    |170
shared_server_sessions              |integer    |

So we see that the process limit is really a session limit. Sessions is a derived parameter an will always be (1.1*PROCESSES)+5 so ignore it.

Over all, as noted in the Wikipedia article, Windows has a cheap thread, heavy process architecture. I have experienced threadthrashing  with MySql on Linux due to a patch deficient setup, but I have yet to see this on Windows even in MySql.

>From Above link:

"At the other extreme a server could create a big pool of threads so that virtually every client request is processed by a dedicated thread. This scenario usually leads to thread-thrashing, where lots of threads wake-up, perform some CPU processing, block waiting for I/O and then after request procesing is completed block again waiting for a new request. If nothing else, context-switches are caused by the scheduler having to divide processor time among multiple active threads."

As we've seen, Oracle spawns a new thread for each connection, so the concern appears to valid, but pragmatically speaking, it probably isn't worth worrying about until you see it, and as you'll read in the article, Windows accounted for this NT 3.5. and Oracle has good programmers, so...There. Received on Fri Jun 08 2007 - 23:32:22 CDT

Original text of this message