IDS Forum

Re: Number of dbaccess/OS process per os session

Posted By: Art Kagel
Date: Friday, 9 October 2009, at 6:58 a.m.

In Response To: Re: Number of dbaccess/OS process per os session (jak aka)

OK, so you have 48 real CPU Cores, so if you disable the hardware threads
you can probably handle the 96 CPU VPs. With the threading turned on I
wouldn't set up more than 48 CPU VPs and I would definitely use the affinity
options to the VPCLASS cpu setting to pin the VPs to the first thread on
each core (careful Sun doesn't necessarily number the processors
sequentially and doesn't always start with zero - it depends on which slots
the processor boards are in).

On the ipcshm NETTYPE: If you turn shared memory connections back on, I
would have listeners running in at least half of the CPU VPs. Personally I
like them running in all CPU VPs but 96 listeners is more than you probably
need.

On the tlitcp NETTYPE: IBM says that a single listener can handle up to
about 1500 connections, but recommends that you keep it under about 350, so
if you want to handle 10,000 connections with less delay time, change that
to:

NETTYPE tlitcp 30,350,NET

Give that a shot.

Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.

On Thu, Oct 8, 2009 at 10:22 PM, jak aka <jakkritakeng@yahoo.com> wrote:

> We set Nettype to
> ipcshm,2,100,CPU
> tiltcp,10,1000,NET
>
> DBSERVERNAME port1
> DBSERVERALIASES port2,port3,port4
>
> In sqlhost file we have 4 port
> port1 ontiltcp servername 2221 r=0,s=2
> port2 ontiltcp servername 2222 r=0,s=2
> port3 ontiltcp servername 2223 r=0,s=2
> port4 ontiltcp servername 2224 r=0,s=2
>
> CPU Model
> sprac 64 VII
> 4 core per physical cpu
> 2 thread per core
> Total 96 CPU core
>
> Best regards,
> Jakkrit A.
>
> --- On Thu, 10/8/09, Art Kagel <art.kagel@gmail.com> wrote:
>
> From: Art Kagel <art.kagel@gmail.com>
> Subject: Re: Number of dbaccess/OS process per os session [17429]
> To: ids@iiug.org
> Date: Thursday, October 8, 2009, 10:48 AM
>
> You ask "How do I make connection time faster...?" Well, you would adjust
> your NETTYPE settings, which is why I asked what settings you are using. If
> you post your NETTYPE settings, I'll try to help.
>
> Also, do you REALLY have 96 processors? Or do you rather have 4x4 core
> Niagra II processors with 8 hardware threads each? You did not say what
> kind of hardware you were running on. It is critical to getting good advice
> that you tell us everything you know!
>
> If that's it, then you actually only have 16 CPU cores and you should
> configure the ONCONFIG file assuming that and IB you should disable the
> hardware threads. They interfere with the way the oninit processes work and
> will SLOW the engine down significantly. If you disable the threads you can
> configure up to 48 CPU VPs (3 per core) but I'd recommend using only 2 on
> these processors, they are barely fast enough to run 3 CPU VPS each. Also
> if you decide to keep the hardware threads running you should use the aff
> option to the VPCLASS cpu setting to pin the CPU VPs to the first hardware
> thread in each processor (ie 0, 8, 16, 24, 32, etc.). VPs should never be
> run on multiple hardware threads in the same CPU core.
>
> Art
>
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Oninit, the IIUG, nor any other organization
> with which I am associated either explicitly or implicitly. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
> On Thu, Oct 8, 2009 at 5:47 AM, jak aka <jakkritakeng@yahoo.com> wrote:
>
> > Hi,
> > Sorry , May be my question is a little confuse. My situation is :
> >
> > When I treid to use dbaccess or ESQL program connect to database
> > concurrently
> > 1000 session or more.
> > Then I use dbaccess/ESQL to connect database , I have to wait for a
> moment
> > (may be 10 sec or more thane 1 minute) .
> >
> > I would like to decrease the waitting time for new connection (while many
> > of
> > transactions connecting database). How to make the connection time faster
> ?
> >
> > The root problem is after I migrating database from Solaris8 to
> Solaris10.
> > I
> > got slow connection problem. We migrated by unplug disk
> > from old machine (sol8) and plug into new machine (sol10).
> >
> > NETTYPE- I 've tried both onsoctcp and ontlitcp
> >
> > Total concurrent connection - 10,000 or more
> >
> > CPU - 96
> >
> > CPUVPS - 48
> >
> > USE Raw device
> >
> > DIRECT_IO is turned off
> >
> > Best regards,
> > Jakkrit A.
> >
> > --- On Wed, 10/7/09, Art Kagel <art.kagel@gmail.com> wrote:
> >
> > From: Art Kagel <art.kagel@gmail.com>
> > Subject: Re: Number of dbaccess/OS process per os session [17398]
> > To: ids@iiug.org
> > Date: Wednesday, October 7, 2009, 6:31 AM
> >
> > OK, let's get practical. What are the NETTYPE settings for the connection
> > type you are trying to use to connect to this instance? How many physical
> > CPU cores are there? How many CPU VPS are configured? Are the disks RAW
> or
> > COOKED? If COOKED do you have DIRECT_IO enabled? If not, how many AIO VPS
> > are configured?
> >
> > Art
> >
> > Art S. Kagel
> > Oninit (www.oninit.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and
> > do not reflect on my employer, Oninit, the IIUG, nor any other
> organization
> > with which I am associated either explicitly or implicitly. Neither do
> > those opinions reflect those of other individuals affiliated with any
> > entity
> > with which I am affiliated nor those of the entities themselves.
> >
> > On Wed, Oct 7, 2009 at 12:01 AM, jak aka <jakkritakeng@yahoo.com> wrote:
> >
> > > Hi,
> > >
> > > Thank you for your response.
> > >
> > > No loads because this is new machine (testing machine) and my script
> just
> > > only
> > > "sleep 100". No any CPU consuming process.
> > >
> > > What 's OS or hardware limitation that you recommend to check ?
> > >
> > > informix [ne3m9k] on_nebula33 $ ulimit -a
> > > time(seconds) unlimited
> > > file(blocks) unlimited
> > > data(kbytes) unlimited
> > > stack(kbytes) 8192
> > > coredump(blocks) unlimited
> > > nofiles(descriptors) 1048576
> > > vmemory(kbytes) unlimited
> > > informix [ne3m9k] on_nebula33 $ projects
> > >
> > > default user.informix user.ritthicp
> > > informix [ne3m9k] on_nebula33 $ projects -l user.informix
> > > user.informix
> > >
> > > projid : 1001
> > >
> > > comment: "Informix's Project"
> > >
> > > users : informix
> > >
> > > groups : informix
> > >
> > > attribs: project.max-sem-ids=(priv,4096,deny)
> > >
> > > project.max-shm-ids=(priv,500,deny)
> > >
> > > project.max-shm-memory=(priv,4398046511104,deny)
> > >
> > > process.max-file-descriptor=(priv,1048576,deny)
> > >
> > > informix [ne3m9k] on_nebula33 $ uname -a
> > > SunOS ne3m9k 5.10 Generic_141414-07 sun4u sparc SUNW,SPARC-Enterprise
> > > informix [ne3m9k] on_nebula33 $ onstat -version
> > > Program Name: onstat
> > > Build Version: 10.00.FC10W2X
> > > Build Number: N008
> > > Build Host: digger2
> > > Build OS: SunOS-sparc 5.8
> > > Build Date: Wed Aug 12 15:44:50 CDT 2009
> > > GLS Version: glslib-4.00.FC12
> > >
> > > Best regards,
> > > Jakkrit A.
> > > --- On Tue, 10/6/09, Art Kagel <art.kagel@gmail.com> wrote:
> > >
> > > From: Art Kagel <art.kagel@gmail.com>
> > > Subject: Re: Number of dbaccess/OS process per os session [17394]
> > > To: ids@iiug.org
> > > Date: Tuesday, October 6, 2009, 11:38 PM
> > >
> > > Are you trying to run 20,000 concurrent processes all local on a Sun
> > M9000?
> > > Perhaps you are running into OS and hardware limitations. What's the
> > > system load look like when you are doing that? I've seen an M9000
> running
> > > with that many processes, but not all actively running.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Oninit (www.oninit.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Oninit, the IIUG, nor any other
> > organization
> > > with which I am associated either explicitly or implicitly. Neither do
> > > those opinions reflect those of other individuals affiliated with any
> > > entity
> > > with which I am affiliated nor those of the entities themselves.
> > >
> > > On Tue, Oct 6, 2009 at 10:20 PM, jak aka <jakkritakeng@yahoo.com>
> wrote:
> > >
> > > > Hi ,
> > > >
> > > > I got a problem when I run dbaccess 10,000 concurrent session (I
> tried
> > > with
> > > > user informix and another user) but dbaccess can run only around
> 4,0xx
> > > > concurrent sessions.
> > > >
> > > > While 4,0xx concurrent 're running I open another sesession and use
> > > > dbaccess
> > > > to connect database, I can connect but have to wait for a moment (4-5
> > > sec).
> > > >
> > > > I also tried to run "sleep 100" 10,000 concurrent. It's the same. For
> > > that
> > > > session I can run only 4,xxx concurrent (ps -ef |grep "sleep 100").
> > > >
> > > > However, If I open another session (terminal) and run "sleep 100"
> > another
> > > > 10,000 concurrent , no problem ,I can run another 4,xxx concurrent.
> > > >
> > > > I use "ps -ef" to count total "sleep 100" . I got total 8,xxx
> > concurrent
> > > > (from
> > > > 1st session and 2nd session).
> > > >
> > > > Does anyone experience this situation ?
> > > >
> > > > OS: Sun solaris 10 (M9000 model)
> > > > IDS: IDS.10.00FC6
> > > >
> > > > Best regards,
> > > > Jakkrit A.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
> *******************************************************************************
> > > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > > >
> > > >
> > >
> > > --0023545bd760207d53047550158d
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> *******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> *******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --0015173fe6c689b5af047555d97c
> >
> >
> >
> >
>
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --0023545bd658dff08e04756d8cc6
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--00151747bfe20460c104757e7650

Messages In This Thread

• Number of dbaccess/OS process per os session
  jak aka -- Tuesday, 6 October 2009, at 10:20 p.m.
  • Re: Number of dbaccess/OS process per os session
    Art Kagel -- Tuesday, 6 October 2009, at 11:38 p.m.
    • Re: Number of dbaccess/OS process per os session
      jak aka -- Wednesday, 7 October 2009, at 12:01 a.m.
      • Re: Number of dbaccess/OS process per os session
        Art Kagel -- Wednesday, 7 October 2009, at 6:31 a.m.
        • Re: Number of dbaccess/OS process per os session
          jak aka -- Thursday, 8 October 2009, at 5:47 a.m.
          • Re: Number of dbaccess/OS process per os session
            Art Kagel -- Thursday, 8 October 2009, at 10:48 a.m.
            • Re: Number of dbaccess/OS process per os session
              jak aka -- Thursday, 8 October 2009, at 10:22 p.m.
              • Re: Number of dbaccess/OS process per os session
                Art Kagel -- Friday, 9 October 2009, at 6:58 a.m.
          • Re: Number of dbaccess/OS process per os session
            JACQUES RENAUT -- Friday, 9 October 2009, at 9:34 a.m.
            • Re: Number of dbaccess/OS process per os session
              jak aka -- Friday, 9 October 2009, at 11:50 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.