Re: 10.2.0.4 / New Hugepages / JDBC Thin connections slow connect ?
From: Hans Forbrich <fuzzy.graybeard_at_gmail.com>
Date: Mon, 24 Jun 2013 17:37:48 -0600
Message-ID: <51C8D84C.1050108_at_gmail.com>
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?
Date: Mon, 24 Jun 2013 17:37:48 -0600
Message-ID: <51C8D84C.1050108_at_gmail.com>
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-lReceived on Tue Jun 25 2013 - 01:37:48 CEST