Re: shared server configuration

From: Maureen English <maureen.english_at_alaska.edu>
Date: Thu, 21 Oct 2010 10:16:30 -0800
Message-ID: <4CC0837E.3010203_at_alaska.edu>



Robert, (rest of list);

We've always left sessions at the default derived from processes. I thought that shared_server_sessions would be the parameter that needed to be modified instead.... When I saw no decrease in sessions last night while testing, I started wondering about the need to increase the sessions parameter.

For starting values for shared servers, I've been using Oracle's suggested 10% calculation.

On a normal day, we have about 100 dedicated server connections from the application. So, my plan was to start 10 shared servers and expect that each shared server can handle what would have been 10 dedicated server connections.

Twice a year we have a problem when more than 100 people try to do the same thing at the same time. We figured that the highest number might be 5000 - our system started swapping badly when dedicated server connections reached about 1800+ and then another machine crashed so we never found out what the max was, this is just a worst case scenario number.

There's no way we can handle 5000 dedicated server connections, but we certainly can handle 500 shared server connections. So, the plan is to increase the number of shared servers from 100 to maybe 500 just before we see this increase in activity (it's predictable, midnight when registration opens).

If we truly do have 5000 simultaneous users trying to connect, would that equate to 5000 sessions, or 5000 shared server sessions, or both?

Regarding dispatchers, Thanks, you answered my unasked question! I knew we had way too many starting up! Per lsnrctl, each dispatcher has a max:2046. I'd say that 3 dispatchers is plenty even for our worst case scenario.

  • Maureen

Goulet, Richard wrote:
> Maureen,
>
> To start with processes and sessions are two separate parameters
> in your init/spfile and having different values is not a problem,
> mostly. Sessions should be equal to or greater than processes. As for
> shared server mode the biggest problem is not having an idle shared
> server when it's needed. In that case the end user must wait till one
> is available. Now you can set max_shared_servers higher than
> shared_servers and Oracle will start/stop serves as it needs, just don't
> hold your breath. Starting and stopping shared server processes is a
> background task for smon so it doesn't react rapidly. To get around
> that you really need to know that your average active session count is
> through out a typical day. That + 50% is what I'd set shared servers
> to, better to have a pile of idle shared server processes than a client
> waiting. MAX_SHARED_SERVERS I'd set to 60% or processes and sessions to
> processes*2.
>
> Yes this can save you a pile of memory since a shared server
> takes up a little less that half the memory of a dedicated server, but
> the downfall above needs to be considered. BTW: Take a look at the max
> sessions your dispatchers can handle, some operating systems allow this
> to be higher than others. Now take your expected max session load and
> divide that by the max sessions per dispatcher multiplied by 0.75.
> Here's an example:
>
> I'm on Linux with Oracle 11.1.0.7. Max sessions per dispatcher
> is 972 (lsnrctl services will tell you). Now you say your expecting
> 5000 sessions max. So the dispatchers parameter should be set to
> ceil(5000/(972*.075)) or 69 dispatchers in my case which would cause me
> to visit the application designers since their connection pool probably
> isn't that large.
>
>
> Dick Goulet
> Senior Oracle DBA
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Oct 21 2010 - 13:16:30 CDT

Original text of this message