Re: 10.2.0.4 / New Hugepages / JDBC Thin connections slow connect ?
From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Mon, 24 Jun 2013 20:07:03 -0500
Message-Id: <17F0DA92-8360-4FB9-A613-9E11C3E4CDBD_at_gmail.com>
Thanks Hans. It appears it's only a few threads that get started and then are slow to connect.
> First thought is that you are exceeding the rate that the listener can
> spawn off new connections. How many of these connections per second are
> they attempting?
>
> Going entirely from memory ... Anything past a few dozen to a few
> hundred new 'dedicated server' connections/second is likely
> unrealistic. IIRC, the listener is trying to spawn off brand new
> processes (fork & exec style), so the OS needs to find memory for an
> entire process and load an entire oracle server image into memory from
> the $ORACLE_HOME/bin/oracle executable. And I believe the fork system
> call is blocking, so has to happen one-at-a-time ... create a whole
> server process before the listener can handle the next request.
>
> If it is indeed the listener rate, can they switch those specific
> connections to shared server? Using the OCI driver, they should be
> able to specify (SERVER=SHARED) in the description.
>
> /Hans
> --
> http://www.freelists.org/webpage/oracle-l
>
>
Date: Mon, 24 Jun 2013 20:07:03 -0500
Message-Id: <17F0DA92-8360-4FB9-A613-9E11C3E4CDBD_at_gmail.com>
Thanks Hans. It appears it's only a few threads that get started and then are slow to connect.
Josh Collier also mentioned checking the port usage on the JDBC machine.
I really think it's PRE_PAGE_SGA with this size buffer cache as none of the other dev/qa instances exhibit this behavior and have much smaller cache sizes.
We're going to schedule some tests.
Chris
Sent from my mobile device. Please ignore any typos.
On Jun 24, 2013, at 6:37 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com> wrote:
> On 24/06/2013 4:39 PM, Christopher.Taylor2_at_parallon.net wrote:
>> ... We have 1 application that is having a problem and it is a JAVA process that spawns many dedicated, short lived, JDBC connection threads. One of the threads it spins off connects and exits quickly and is responsible for moving jobs from a queued to a running status.
> First thought is that you are exceeding the rate that the listener can
> spawn off new connections. How many of these connections per second are
> they attempting?
>
> Going entirely from memory ... Anything past a few dozen to a few
> hundred new 'dedicated server' connections/second is likely
> unrealistic. IIRC, the listener is trying to spawn off brand new
> processes (fork & exec style), so the OS needs to find memory for an
> entire process and load an entire oracle server image into memory from
> the $ORACLE_HOME/bin/oracle executable. And I believe the fork system
> call is blocking, so has to happen one-at-a-time ... create a whole
> server process before the listener can handle the next request.
>
> If it is indeed the listener rate, can they switch those specific
> connections to shared server? Using the OCI driver, they should be
> able to specify (SERVER=SHARED) in the description.
>
> /Hans
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 25 2013 - 03:07:03 CEST