Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Thread Thrashing under Win32
On Jun 8, 8:07 pm, joel garry <joel-ga..._at_home.com> wrote:
> On Jun 8, 11:28 am, BD <robert.d..._at_gmail.com> wrote:
>
>
>
> > I'm working with a developer to deploy Oracle db 10.2.0.3 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."http://ewhalen.blogspot.com/2006_05_01_ewhalen_archive.html
>
> White paper that notes threads switch context faster than processes
> and share more data structures:http://www.oracle.com/technology/tech/windows/rdbms/Oracle_10gR2_Wind...
>
> 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
> --
> @home.com is bogus.
> Windows tuning: http://www.signonsandiego.com/uniontrib/20070608/images/news-pig220.jpg
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. http://en.wikipedia.org/wiki/Thread_%28computer_science%29#Threads_compared_with_processes
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?
Again:
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.
Example:
No connections in database:
C:\work\admin\sysinternals>pslist |grep "oracle"
Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time oracle 1128 8 26 532 655236 0:00:54.1250:37:30.593
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
ERROR:
ORA-00020: maximum number of processes (%s) exceeded
Using an existing connection we see the following:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
23:43:50 SCOTT_at_BJORK4> select count(*) from v$session;
COUNT(*)
146
Elapsed: 00:00:00.00
23:47:49 SCOTT_at_BJORK4> select count(*) from v$process;
COUNT(*)
149
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.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams190.htm#REFRN10197
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. http://www.microsoft.com/technet/sysinternals/information/iocompletionports.mspx
>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