Re: Threaded execution (was: Interesting Bugs in 12cR1)

From: Frits Hoogland <frits.hoogland_at_gmail.com>
Date: Fri, 12 Jul 2013 19:28:36 +0200
Message-ID: <-7732013081497748927_at_unknownmsgid>



It depends on where the time is spend. Use perf top or record to measure functions for threaded and non threaded performance. My guess is most time is spend in populating memory for a new connection, which does not change with threads vs. processes. Frits Hoogland

http://fritshoogland.wordpress.com
frits.hoogland_at_gmail.com
+31 6 53569942

(Sent from my iPhone, typo's are expected)

Op 12 jul. 2013 om 17:49 heeft Yong Huang <yong321_at_yahoo.com> het volgende geschreven:

>> I've been looking at threaded execution and came across the sys auth issue,
>> to date I've yet to find any great benefit for this process model, which
>> isn't the default.
> I did a quick test on the performance of establishing and disconnecting local sessions on a not very fast RHEL 5 box. With threaded_execution, making 200 sessions takes 2 seconds. Without, it takes 3 seconds. The test is done more than 20 times and the first measurement is discarded. The timing is accurate, rarely off by 1 second. I think this execution model is meant to make fork (clone) and exec more lightweight. For any reason you can't use shared server config, this is an alternative, so you still have a dedicated session and its own trace file, etc. The shadow "process" becomes shadow thread. (But I remember the number of Linux threads counts against user's process limit, i.e. ulimit -u.)
>
>
> Yong Huang
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jul 12 2013 - 19:28:36 CEST

Original text of this message