Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

dbsrv9 thread devouring CPU

11 posts in General Discussion Last posting was on 2004-09-14 13:12:35.0Z
Steve Burbrink Posted on 2004-07-21 20:59:09.0Z
Reply-To: "Steve Burbrink" <sywalters@hotmail.com>
From: "Steve Burbrink" <sywalters@hotmail.com>
Newsgroups: ianywhere.public.general
Subject: dbsrv9 thread devouring CPU
Lines: 21
Organization: Compass Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: ztown2-1-18.adsl.one.net
X-Original-NNTP-Posting-Host: ztown2-1-18.adsl.one.net
Message-ID: <40fed91d$1@forums-1-dub>
Date: 21 Jul 2004 13:59:09 -0700
X-Trace: forums-1-dub 1090443549 216.23.33.18 (21 Jul 2004 13:59:09 -0700)
X-Original-Trace: 21 Jul 2004 13:59:09 -0700, ztown2-1-18.adsl.one.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3288
Article PK: 7202

I've posted this to the Linux group with little success :

I have a Linux drsrv9 thread that consumes 99% of the CPU. Everything
seems ok (connections can be made, performance is ok) but eventually (after
a day or so) I notice messages is in the /var/log/message file :

"Connection terminated abnormally; server socket shut down"...

I'm starting the server with the following command line args:
dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x tcpip{ServerPort=4200}
/usr/local/project/blah.db"

Are these messages (connection terminated) and the 99% dbsrv9 thread
related?

Any ideas??

Thanks,
Steve


Jason Hinsperger (iAnywhere) Posted on 2004-07-22 11:57:34.0Z
From: "Jason Hinsperger \(iAnywhere\)" <NOjason_hinspergerSPAM@hotmail.com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 48
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Original-NNTP-Posting-Host: vpn-concord-044.sybase.com
Message-ID: <40ffaca1@forums-2-dub>
X-Original-Trace: 22 Jul 2004 05:01:37 -0700, vpn-concord-044.sybase.com
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 22 Jul 2004 04:50:49 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 22 Jul 2004 04:57:34 -0700
X-Trace: forums-1-dub 1090497454 10.22.108.75 (22 Jul 2004 04:57:34 -0700)
X-Original-Trace: 22 Jul 2004 04:57:34 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3291
Article PK: 7201

They could be related, however, they may not be indicating that there is
anything wrong at all. Are you experiencing a specific problem related to
these symtpms?
When the server is consuming significant CPU, this doesn't necessarily mean
there is a problem.
Similarly, the abrnormal shutdown message doesn't necessarily indicate a
problem either. It means that for some reason (other than a normal
disconnect), the tcpip connection between a client and the server went away.

Have you turned on request level logging to see what the server is doing?

--
Jason Hinsperger
Product Manager
iAnywhere Solutions
************************************************************
For the latest downloads technotes, whitepapers, webcasts and other
developer
resources, go to: http://www.ianywhere.com/developer/
************************************************************

"Steve Burbrink" <sywalters@hotmail.com> wrote in message
news:40fed91d$1@forums-1-dub...
> I've posted this to the Linux group with little success :
>
> I have a Linux drsrv9 thread that consumes 99% of the CPU. Everything
> seems ok (connections can be made, performance is ok) but eventually
(after
> a day or so) I notice messages is in the /var/log/message file :
>
> "Connection terminated abnormally; server socket shut down"...
>
> I'm starting the server with the following command line args:
> dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x tcpip{ServerPort=4200}
> /usr/local/project/blah.db"
>
> Are these messages (connection terminated) and the 99% dbsrv9 thread
> related?
>
> Any ideas??
>
> Thanks,
> Steve
>
>


Steve Burbrink Posted on 2004-07-22 19:04:18.0Z
Reply-To: "Steve Burbrink" <sywalters@hotmail.com>
From: "Steve Burbrink" <sywalters@hotmail.com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 78
Organization: Compass Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Original-NNTP-Posting-Host: ztown2-1-18.adsl.one.net
Message-ID: <410010a6$1@forums-2-dub>
X-Original-Trace: 22 Jul 2004 12:08:22 -0700, ztown2-1-18.adsl.one.net
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 22 Jul 2004 11:57:31 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 22 Jul 2004 12:04:18 -0700
X-Trace: forums-1-dub 1090523058 10.22.108.75 (22 Jul 2004 12:04:18 -0700)
X-Original-Trace: 22 Jul 2004 12:04:18 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3296
Article PK: 7205

Initially, I have 32 threads which are consuming about 2-3% CPU each...
which is what I would expect....
After some event (or time?), a single thread jumps to 99% CPU...

I have shutdown the local processes communicting to the dbsrv engine and the
thread continues to consume CPU.

I have not turned on request level logging (yet) ...

I'm not sure that the 99% CPU consumation is actually causing me a problem,
it just doesn't seem right...

How does the dbsrv9 engine decide to spawn its threads (ie. one for each
client connection, etc...)

My application is using no triggers ... only scheduled events.

What would happen if a schedule event overlapped itself ? (ie. an event
that's scheduled to run every 5 seconds but requires more than 5 seconds to
complete?)

Steve

"Jason Hinsperger (iAnywhere)" <NOjason_hinspergerSPAM@hotmail.com> wrote in
message news:40ffaca1@forums-2-dub...
> They could be related, however, they may not be indicating that there is
> anything wrong at all. Are you experiencing a specific problem related to
> these symtpms?
> When the server is consuming significant CPU, this doesn't necessarily
mean
> there is a problem.
> Similarly, the abrnormal shutdown message doesn't necessarily indicate a
> problem either. It means that for some reason (other than a normal
> disconnect), the tcpip connection between a client and the server went
away.
>
> Have you turned on request level logging to see what the server is doing?
>
> --
> Jason Hinsperger
> Product Manager
> iAnywhere Solutions
> ************************************************************
> For the latest downloads technotes, whitepapers, webcasts and other
> developer
> resources, go to: http://www.ianywhere.com/developer/
> ************************************************************
>
>
> "Steve Burbrink" <sywalters@hotmail.com> wrote in message
> news:40fed91d$1@forums-1-dub...
> > I've posted this to the Linux group with little success :
> >
> > I have a Linux drsrv9 thread that consumes 99% of the CPU. Everything
> > seems ok (connections can be made, performance is ok) but eventually
> (after
> > a day or so) I notice messages is in the /var/log/message file :
> >
> > "Connection terminated abnormally; server socket shut down"...
> >
> > I'm starting the server with the following command line args:
> > dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x tcpip{ServerPort=4200}
> > /usr/local/project/blah.db"
> >
> > Are these messages (connection terminated) and the 99% dbsrv9 thread
> > related?
> >
> > Any ideas??
> >
> > Thanks,
> > Steve
> >
> >
>
>


Greg Fenton Posted on 2004-07-22 19:46:42.0Z
From: Greg Fenton <greg.fenton_NOSPAM_@ianywhere.com>
Organization: iAnywhere Solutions Inc.
User-Agent: Mozilla Thunderbird 1.6.3.2f (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: dbsrv9 thread devouring CPU
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub>
In-Reply-To: <410010a6$1@forums-2-dub>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Original-NNTP-Posting-Host: gfenton-xp.sybase.com
Message-ID: <41001a96$1@forums-2-dub>
X-Original-Trace: 22 Jul 2004 12:50:46 -0700, gfenton-xp.sybase.com
Lines: 41
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 22 Jul 2004 12:39:55 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 22 Jul 2004 12:46:42 -0700
X-Trace: forums-1-dub 1090525602 10.22.108.75 (22 Jul 2004 12:46:42 -0700)
X-Original-Trace: 22 Jul 2004 12:46:42 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3297
Article PK: 7206


Steve Burbrink wrote:
>
> I'm not sure that the 99% CPU consumation is actually causing me a problem,
> it just doesn't seem right...
>

Is it staying at 99% indefinitely?

> How does the dbsrv9 engine decide to spawn its threads (ie. one for each
> client connection, etc...)

By default the engine runs with one thread per CPU. The engine
maintains its own list of work to be done ("tasks"). Each request made
by a connection adds one (or more) tasks to the list.

You can modify the number of CPUs which the engine will use with the
"-gt" flag, but obviously it will only use as many CPUs as are available
(or that you are licensed for).

I'm not entirely sure how the engine behaves w.r.t. hyperthreading.

> What would happen if a schedule event overlapped itself ? (ie. an event
> that's scheduled to run every 5 seconds but requires more than 5 seconds to
> complete?)
>

Each Event fires in their own separate database connection. So if the
above were the case, then you'd have two separate connections running
the same event code simultaneously.


I am about to respond to your post in the Linux newsgroup next.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/


"Bruce Hay" Posted on 2004-07-23 12:40:45.0Z
From: "Bruce Hay" <hay at sybase dot com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 23
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Original-NNTP-Posting-Host: hay-xp.sybase.com
Message-ID: <41010845@forums-2-dub>
X-Original-Trace: 23 Jul 2004 05:44:53 -0700, hay-xp.sybase.com
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 23 Jul 2004 05:33:54 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 23 Jul 2004 05:40:45 -0700
X-Trace: forums-1-dub 1090586445 10.22.108.75 (23 Jul 2004 05:40:45 -0700)
X-Original-Trace: 23 Jul 2004 05:40:45 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3299
Article PK: 7212


"Steve Burbrink" <sywalters@hotmail.com> wrote in message
news:410010a6$1@forums-2-dub...
> What would happen if a schedule event overlapped itself ? (ie. an event
> that's scheduled to run every 5 seconds but requires more than 5 seconds
to
> complete?)

The event will re-schedule itself once it completes, so it will fire less
frequently. For example, if it requires 7 seconds to complete, it will
execute every 10 seconds instead of every 5.

See the section:
ASA Database Administration Guide

Automating Tasks Using Schedules and Events

Schedule and event internals

How the database server checks for scheduled events
Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer


Greg Fenton Posted on 2004-07-23 14:53:42.0Z
From: Greg Fenton <greg.fenton_NOSPAM_@ianywhere.com>
Organization: iAnywhere Solutions Inc.
User-Agent: Mozilla Thunderbird 1.6.3.2f (Windows/20040707)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: dbsrv9 thread devouring CPU
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub>
In-Reply-To: <41010845@forums-2-dub>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: gfenton-xp.sybase.com
X-Original-NNTP-Posting-Host: gfenton-xp.sybase.com
Message-ID: <41012676$1@forums-1-dub>
Date: 23 Jul 2004 07:53:42 -0700
X-Trace: forums-1-dub 1090594422 10.25.100.188 (23 Jul 2004 07:53:42 -0700)
X-Original-Trace: 23 Jul 2004 07:53:42 -0700, gfenton-xp.sybase.com
Lines: 18
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3302
Article PK: 7213


Bruce Hay wrote:
>
> The event will re-schedule itself once it completes, so it will fire less
> frequently. For example, if it requires 7 seconds to complete, it will
> execute every 10 seconds instead of every 5.
>

Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
average cron"! :-)

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/


Steve Burbrink Posted on 2004-07-23 16:06:07.0Z
Reply-To: "Steve Burbrink" <sywalters@hotmail.com>
From: "Steve Burbrink" <sywalters@hotmail.com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub> <41012676$1@forums-1-dub>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 28
Organization: Compass Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Original-NNTP-Posting-Host: nr28-66-161-169-12.fuse.net
Message-ID: <41013867$1@forums-2-dub>
X-Original-Trace: 23 Jul 2004 09:10:15 -0700, nr28-66-161-169-12.fuse.net
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 23 Jul 2004 08:59:15 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 23 Jul 2004 09:06:07 -0700
X-Trace: forums-1-dub 1090598767 10.22.108.75 (23 Jul 2004 09:06:07 -0700)
X-Original-Trace: 23 Jul 2004 09:06:07 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3303
Article PK: 7220

Thanks for the insight....
But... How can I get details on what a specific dbsrv9 thread is doing?

Are they handling client connections?

"Greg Fenton" <greg.fenton_NOSPAM_@ianywhere.com> wrote in message
news:41012676$1@forums-1-dub...
> Bruce Hay wrote:
> >
> > The event will re-schedule itself once it completes, so it will fire
less
> > frequently. For example, if it requires 7 seconds to complete, it will
> > execute every 10 seconds instead of every 5.
> >
>
> Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
> average cron"! :-)
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/


Steve Burbrink Posted on 2004-08-02 19:22:30.0Z
Reply-To: "Steve Burbrink" <sywalters@hotmail.com>
From: "Steve Burbrink" <sywalters@hotmail.com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub> <41012676$1@forums-1-dub> <41013867$1@forums-2-dub>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 47
Organization: Compass Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: ztown2-1-18.adsl.one.net
X-Original-NNTP-Posting-Host: ztown2-1-18.adsl.one.net
Message-ID: <410e9476$1@forums-1-dub>
Date: 2 Aug 2004 12:22:30 -0700
X-Trace: forums-1-dub 1091474550 216.23.33.18 (2 Aug 2004 12:22:30 -0700)
X-Original-Trace: 2 Aug 2004 12:22:30 -0700, ztown2-1-18.adsl.one.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3350
Article PK: 7256

I've installed all all update to OS and the dbsrv9.
Red Hat : 2.4.9-e.43smp -
Sybase ASA : 9.0.1 (1753)

I no longer have a single thread utilizing 99% CPU, but I now have a dbsrv9
thread which has gone from 15% to 65% CPU utilization over a period of 2
weeks.

This is a 3.0GHZ Zeon machine, 1.5 GB RAM, a database which contains less
than 50,000 records.

How can I tell what the thread is doing?

Steve

"Steve Burbrink" <sywalters@hotmail.com> wrote in message
news:41013867$1@forums-2-dub...
> Thanks for the insight....
> But... How can I get details on what a specific dbsrv9 thread is doing?
>
> Are they handling client connections?
>
> "Greg Fenton" <greg.fenton_NOSPAM_@ianywhere.com> wrote in message
> news:41012676$1@forums-1-dub...
> > Bruce Hay wrote:
> > >
> > > The event will re-schedule itself once it completes, so it will fire
> less
> > > frequently. For example, if it requires 7 seconds to complete, it will
> > > execute every 10 seconds instead of every 5.
> > >
> >
> > Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
> > average cron"! :-)
> >
> > greg.fenton
> > --
> > Greg Fenton
> > Consultant, Solution Services, iAnywhere Solutions
> > --------
> > Visit the iAnywhere Solutions Developer Community
> > Whitepapers, TechDocs, Downloads
> > http://www.ianywhere.com/developer/
>
>


Mark Culp Posted on 2004-08-16 17:18:53.0Z
Message-ID: <4120EA52.3DE2F212@iAnywhere.com>
From: Mark Culp <reply_to_newsgroups_only_please_nospam_mark.culp@iAnywhere.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: dbsrv9 thread devouring CPU
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub> <41012676$1@forums-1-dub> <41013867$1@forums-2-dub> <410e9476$1@forums-1-dub>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Original-NNTP-Posting-Host: mculp-xp.sybase.com
X-Original-Trace: 16 Aug 2004 10:24:27 -0700, mculp-xp.sybase.com
Lines: 66
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 16 Aug 2004 10:09:40 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 16 Aug 2004 10:18:53 -0700
X-Trace: forums-1-dub 1092676733 10.22.108.75 (16 Aug 2004 10:18:53 -0700)
X-Original-Trace: 16 Aug 2004 10:18:53 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3388
Article PK: 7296

You can use dbconsole or SybaseCentral to find out what queries are running on
the
engine. This should show you what query is causing the thread to consume
process
time.

If the above doesn't help, then you could run a strace on the offending thread
and post a snippet. A process/thread listing ('ps -elf | grep db') with an
indication of which process/thread is the offending one would also be useful
(i.e. we can get an idea of which thread within the engine is consuming CPU
since the engine always starts its threads in the same order).
--
Mark Culp
ASA Development
-------------------------------------------------------------------------
** Whitepapers, TechDocs, bug fixes are all available through the **
** iAnywhere Developer Community at http://www.ianywhere.com/developer **
-------------------------------------------------------------------------

Steve Burbrink wrote:
>
> I've installed all all update to OS and the dbsrv9.
> Red Hat : 2.4.9-e.43smp -
> Sybase ASA : 9.0.1 (1753)
>
> I no longer have a single thread utilizing 99% CPU, but I now have a dbsrv9
> thread which has gone from 15% to 65% CPU utilization over a period of 2
> weeks.
>
> This is a 3.0GHZ Zeon machine, 1.5 GB RAM, a database which contains less
> than 50,000 records.
>
> How can I tell what the thread is doing?
>
> Steve
>
> "Steve Burbrink" <sywalters@hotmail.com> wrote in message
> news:41013867$1@forums-2-dub...
> > Thanks for the insight....
> > But... How can I get details on what a specific dbsrv9 thread is doing?
> >
> > Are they handling client connections?
> >
> > "Greg Fenton" <greg.fenton_NOSPAM_@ianywhere.com> wrote in message
> > news:41012676$1@forums-1-dub...
> > > Bruce Hay wrote:
> > > >
> > > > The event will re-schedule itself once it completes, so it will fire
> > less
> > > > frequently. For example, if it requires 7 seconds to complete, it will
> > > > execute every 10 seconds instead of every 5.
> > > >
> > >
> > > Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
> > > average cron"! :-)
> > >
> > > greg.fenton
> > > --
> > > Greg Fenton
> > > Consultant, Solution Services, iAnywhere Solutions
> > > --------
> > > Visit the iAnywhere Solutions Developer Community
> > > Whitepapers, TechDocs, Downloads
> > > http://www.ianywhere.com/developer/
> >
> >


Steve Burbrink Posted on 2004-09-10 16:47:35.0Z
Reply-To: "Steve Burbrink" <sywalters@hotmail.com>
From: "Steve Burbrink" <sywalters@hotmail.com>
Newsgroups: ianywhere.public.general
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub> <41012676$1@forums-1-dub> <41013867$1@forums-2-dub> <410e9476$1@forums-1-dub> <4120EA52.3DE2F212@iAnywhere.com>
Subject: Re: dbsrv9 thread devouring CPU
Lines: 320
Organization: Compass Engineering
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: ztown2-1-18.adsl.one.net
X-Original-NNTP-Posting-Host: ztown2-1-18.adsl.one.net
Message-ID: <4141daa7$1@forums-1-dub>
Date: 10 Sep 2004 09:47:35 -0700
X-Trace: forums-1-dub 1094834855 216.23.33.18 (10 Sep 2004 09:47:35 -0700)
X-Original-Trace: 10 Sep 2004 09:47:35 -0700, ztown2-1-18.adsl.one.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3515
Article PK: 7418

Mark,
Thanks for the reply....Sorry for the late response.. I'd almost given up..
But, the dbconsole shows connections, those connections all show
STMT_EXECUTE_ANY_IMM:04/0 .. See below

Anyway, I fail to see how the dbserver threads relate to the connections.
I've included the output from top, pstree, and ps-elf.
I've not run the strace yet (don't know how to do it yet).

DBCONSOLE OUTPUT :

Userid Database Last Request
Blocked On Comm. Link ^

169:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
170:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.134
171:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.134
172:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.134
173:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.134
174:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.134
175:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
176:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
177:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
178:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
179:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.129
180:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.128
181:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.128
182:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.128
183:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.128
184:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.128 ?
185:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.135
186:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.135
187:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.135
188:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.135
189:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.135
190:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.115
191:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.115
192:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.115
193:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.115 v
194:cors CORS STMT_EXECUTE_ANY_IMM:04/0
TCPIP:192.168.20.115




From Output from "top" you can see the offending thread here is 1316. I've
"niced" the thread to reduce the overall system impact.

10:33am up 23 days, 22:38, 1 user, load average: 6.19, 5.49, 5.84
174 processes: 161 sleeping, 13 running, 0 zombie, 0 stopped
CPU0 states: 45.1% user, 36.1% system, 0.2% nice, 17.1% idle
CPU1 states: 77.1% user, 15.1% system, 0.1% nice, 7.0% idle
Mem: 1543152K av, 906132K used, 637020K free, 864K shrd, 217596K
buff
Swap: 1052216K av, 0K used, 1052216K free 459384K
cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1316 root 26 1 69664 68M 1800 R N 48.8 4.5 21903m dbsrv9
1302 root 15 -12 69664 68M 1800 R < 36.6 4.5 732:10 dbsrv9
1301 root 7 -12 69664 68M 1800 R < 33.6 4.5 736:30 dbsrv9
1294 root 7 -12 69664 68M 1800 S < 23.9 4.5 728:53 dbsrv9
1295 root 4 -12 69664 68M 1800 S < 2.5 4.5 731:02 dbsrv9
1296 root 4 -12 69664 68M 1800 S < 2.5 4.5 730:08 dbsrv9
1297 root 4 -12 69664 68M 1800 S < 2.5 4.5 732:36 dbsrv9
1299 root 4 -12 69664 68M 1800 S < 2.5 4.5 735:30 dbsrv9
1307 root 4 -12 69664 68M 1800 S < 2.5 4.5 733:59 dbsrv9
1308 root 4 -12 69664 68M 1800 S < 2.1 4.5 827:33 dbsrv9
1312 root 4 -12 69664 68M 1800 S < 2.1 4.5 730:17 dbsrv9
1298 root 4 -12 69664 68M 1800 S < 1.6 4.5 733:41 dbsrv9
1311 root 4 -12 69664 68M 1800 S < 1.6 4.5 730:36 dbsrv9
1313 root 5 -12 69664 68M 1800 S < 1.6 4.5 729:34 dbsrv9
1300 root 4 -12 69664 68M 1800 S < 1.2 4.5 725:59 dbsrv9
1304 root 4 -12 69664 68M 1800 S < 1.2 4.5 729:03 dbsrv9
1306 root 4 -12 69664 68M 1800 S < 1.2 4.5 731:15 dbsrv9
1309 root 4 -12 69664 68M 1800 S < 1.2 4.5 731:15 dbsrv9
1303 root 4 -12 69664 68M 1800 S < 0.8 4.5 729:53 dbsrv9

Output from pstree

[srb@brookstone-cors srb]$ pstree -np | grep dbsrv

|-dbsrv9(1289)---dbsrv9(1291)-+-dbsrv9(1292)

| |-dbsrv9(1293)
| |-dbsrv9(1294)
| |-dbsrv9(1295)
| |-dbsrv9(1296)
| |-dbsrv9(1297)
| |-dbsrv9(1298)
| |-dbsrv9(1299)
| |-dbsrv9(1300)
| |-dbsrv9(1301)
| |-dbsrv9(1302)
| |-dbsrv9(1303)
| |-dbsrv9(1304)
| |-dbsrv9(1305)
| |-dbsrv9(1306)
| |-dbsrv9(1307)
| |-dbsrv9(1308)
| |-dbsrv9(1309)
| |-dbsrv9(1310)
| |-dbsrv9(1311)
| |-dbsrv9(1312)
| |-dbsrv9(1313)
| |-dbsrv9(1314)
| |-dbsrv9(1315)
| |-dbsrv9(1316)
| |-dbsrv9(1317)
| |-dbsrv9(1318)
| |-dbsrv9(1471)
| `-dbsrv9(1472)

Output from ps-elf :

[srb@brookstone-cors srb]$ ps -elf | grep db
040 S root 1289 1 0 63 -12 - 214574 rt_sig Aug17 ?
00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1291 1289 0 63 -12 - 214574 schedu Aug17 ?
00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1292 1291 0 63 -12 - 214574 read_e Aug17 ?
00:00:05 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1293 1291 0 63 -12 - 214574 schedu Aug17 ?
00:01:34 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1294 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:08:54 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1295 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:11:02 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1296 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:10:09 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1297 1291 2 67 -12 - 214574 rt_sig Aug17 ?
12:12:38 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1298 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:13:42 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1299 1291 2 63 -12 - 214574 rt_sig Aug17 ?
12:15:31 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 R root 1300 1291 2 63 -12 - 214574 - Aug17 ?
12:06:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1301 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:16:31 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1302 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:12:10 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1303 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:09:55 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1304 1291 2 68 -12 - 214574 rt_sig Aug17 ?
12:09:05 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1305 1291 0 65 -12 - 214574 rt_sig Aug17 ?
01:28:34 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1306 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1307 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:14:01 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1308 1291 2 64 -12 - 214574 rt_sig Aug17 ?
13:47:35 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1309 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1310 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:11:04 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1311 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:10:36 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1312 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:10:19 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1313 1291 2 64 -12 - 214574 rt_sig Aug17 ?
12:09:35 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1314 1291 0 63 -12 - 214574 semop Aug17 ?
00:03:12 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1315 1291 0 63 -12 - 214574 schedu Aug17 ?
00:00:04 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 R root 1316 1291 63 86 1 - 214574 - Aug17 ?
15-05:03:27 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti
0 -ud -x tcpip{Serv
040 S root 1317 1291 0 63 -12 - 214574 schedu Aug17 ?
00:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1318 1291 0 63 -12 - 214574 schedu Aug17 ?
00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
040 S root 1471 1291 0 63 -12 - 214574 schedu Aug17 ?
00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
140 S root 1472 1291 0 65 -12 - 214574 rt_sig Aug17 ?
00:27:38 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
tcpip{ServerP
000 R srb 4456 4300 0 76 0 - 435 - 10:34 pts/0
00:00:00 grep db


I hope this helps.

Steve

"Mark Culp" <reply_to_newsgroups_only_please_nospam_mark.culp@iAnywhere.com>
wrote in message news:4120EA52.3DE2F212@iAnywhere.com...
> You can use dbconsole or SybaseCentral to find out what queries are
running on
> the
> engine. This should show you what query is causing the thread to consume
> process
> time.
>
> If the above doesn't help, then you could run a strace on the offending
thread
> and post a snippet. A process/thread listing ('ps -elf | grep db') with
an
> indication of which process/thread is the offending one would also be
useful
> (i.e. we can get an idea of which thread within the engine is consuming
CPU
> since the engine always starts its threads in the same order).
> --
> Mark Culp
> ASA Development
> -------------------------------------------------------------------------
> ** Whitepapers, TechDocs, bug fixes are all available through the **
> ** iAnywhere Developer Community at http://www.ianywhere.com/developer **
> -------------------------------------------------------------------------
>
> Steve Burbrink wrote:
> >
> > I've installed all all update to OS and the dbsrv9.
> > Red Hat : 2.4.9-e.43smp -
> > Sybase ASA : 9.0.1 (1753)
> >
> > I no longer have a single thread utilizing 99% CPU, but I now have a
dbsrv9
> > thread which has gone from 15% to 65% CPU utilization over a period of 2
> > weeks.
> >
> > This is a 3.0GHZ Zeon machine, 1.5 GB RAM, a database which contains
less
> > than 50,000 records.
> >
> > How can I tell what the thread is doing?
> >
> > Steve
> >
> > "Steve Burbrink" <sywalters@hotmail.com> wrote in message
> > news:41013867$1@forums-2-dub...
> > > Thanks for the insight....
> > > But... How can I get details on what a specific dbsrv9 thread is
doing?
> > >
> > > Are they handling client connections?
> > >
> > > "Greg Fenton" <greg.fenton_NOSPAM_@ianywhere.com> wrote in message
> > > news:41012676$1@forums-1-dub...
> > > > Bruce Hay wrote:
> > > > >
> > > > > The event will re-schedule itself once it completes, so it will
fire
> > > less
> > > > > frequently. For example, if it requires 7 seconds to complete, it
will
> > > > > execute every 10 seconds instead of every 5.
> > > > >
> > > >
> > > > Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
> > > > average cron"! :-)
> > > >
> > > > greg.fenton
> > > > --
> > > > Greg Fenton
> > > > Consultant, Solution Services, iAnywhere Solutions
> > > > --------
> > > > Visit the iAnywhere Solutions Developer Community
> > > > Whitepapers, TechDocs, Downloads
> > > > http://www.ianywhere.com/developer/
> > >
> > >


Mark Culp Posted on 2004-09-14 13:12:35.0Z
Message-ID: <4146EB73.C25E1299@iAnywhere.com>
From: Mark Culp <reply_to_newsgroups_only_please_nospam_mark.culp@iAnywhere.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: ianywhere.public.general
Subject: Re: dbsrv9 thread devouring CPU
References: <40fed91d$1@forums-1-dub> <40ffaca1@forums-2-dub> <410010a6$1@forums-2-dub> <41010845@forums-2-dub> <41012676$1@forums-1-dub> <41013867$1@forums-2-dub> <410e9476$1@forums-1-dub> <4120EA52.3DE2F212@iAnywhere.com> <4141daa7$1@forums-1-dub>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: iarouter.sybase.com
X-Original-NNTP-Posting-Host: iarouter.sybase.com
Date: 14 Sep 2004 06:12:35 -0700
X-Trace: forums-1-dub 1095167555 10.25.106.45 (14 Sep 2004 06:12:35 -0700)
X-Original-Trace: 14 Sep 2004 06:12:35 -0700, iarouter.sybase.com
Lines: 334
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:3536
Article PK: 7438

So it looks like pid 1316 is using a lot of CPU - this thread is a "worker"
thread within the engine, and therefore it is processing a database request.
Are you sure you don't have a query that has gone awry? If you turn on
request level logging and review the output, you may be able to see which query
that is causing the worker to run so long.

If that does not point you in the right direction, grap an strace output
of the process (after the problem starts), and post a snippet here and we
may be able to identify what is happening within the thread?

--
Mark Culp
ASA Development
-------------------------------------------------------------------------
** Whitepapers, TechDocs, bug fixes are all available through the **
** iAnywhere Developer Community at http://www.ianywhere.com/developer **
-------------------------------------------------------------------------

Steve Burbrink wrote:
>
> Mark,
> Thanks for the reply....Sorry for the late response.. I'd almost given up..
> But, the dbconsole shows connections, those connections all show
> STMT_EXECUTE_ANY_IMM:04/0 .. See below
>
> Anyway, I fail to see how the dbserver threads relate to the connections.
> I've included the output from top, pstree, and ps-elf.
> I've not run the strace yet (don't know how to do it yet).
>
> DBCONSOLE OUTPUT :
>
> Userid Database Last Request
> Blocked On Comm. Link ^
>
> 169:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 170:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.134
> 171:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.134
> 172:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.134
> 173:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.134
> 174:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.134
> 175:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 176:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 177:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 178:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 179:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.129
> 180:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.128
> 181:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.128
> 182:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.128
> 183:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.128
> 184:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.128 ?
> 185:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.135
> 186:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.135
> 187:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.135
> 188:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.135
> 189:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.135
> 190:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.115
> 191:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.115
> 192:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.115
> 193:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.115 v
> 194:cors CORS STMT_EXECUTE_ANY_IMM:04/0
> TCPIP:192.168.20.115
>
> From Output from "top" you can see the offending thread here is 1316. I've
> "niced" the thread to reduce the overall system impact.
>
> 10:33am up 23 days, 22:38, 1 user, load average: 6.19, 5.49, 5.84
> 174 processes: 161 sleeping, 13 running, 0 zombie, 0 stopped
> CPU0 states: 45.1% user, 36.1% system, 0.2% nice, 17.1% idle
> CPU1 states: 77.1% user, 15.1% system, 0.1% nice, 7.0% idle
> Mem: 1543152K av, 906132K used, 637020K free, 864K shrd, 217596K
> buff
> Swap: 1052216K av, 0K used, 1052216K free 459384K
> cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 1316 root 26 1 69664 68M 1800 R N 48.8 4.5 21903m dbsrv9
> 1302 root 15 -12 69664 68M 1800 R < 36.6 4.5 732:10 dbsrv9
> 1301 root 7 -12 69664 68M 1800 R < 33.6 4.5 736:30 dbsrv9
> 1294 root 7 -12 69664 68M 1800 S < 23.9 4.5 728:53 dbsrv9
> 1295 root 4 -12 69664 68M 1800 S < 2.5 4.5 731:02 dbsrv9
> 1296 root 4 -12 69664 68M 1800 S < 2.5 4.5 730:08 dbsrv9
> 1297 root 4 -12 69664 68M 1800 S < 2.5 4.5 732:36 dbsrv9
> 1299 root 4 -12 69664 68M 1800 S < 2.5 4.5 735:30 dbsrv9
> 1307 root 4 -12 69664 68M 1800 S < 2.5 4.5 733:59 dbsrv9
> 1308 root 4 -12 69664 68M 1800 S < 2.1 4.5 827:33 dbsrv9
> 1312 root 4 -12 69664 68M 1800 S < 2.1 4.5 730:17 dbsrv9
> 1298 root 4 -12 69664 68M 1800 S < 1.6 4.5 733:41 dbsrv9
> 1311 root 4 -12 69664 68M 1800 S < 1.6 4.5 730:36 dbsrv9
> 1313 root 5 -12 69664 68M 1800 S < 1.6 4.5 729:34 dbsrv9
> 1300 root 4 -12 69664 68M 1800 S < 1.2 4.5 725:59 dbsrv9
> 1304 root 4 -12 69664 68M 1800 S < 1.2 4.5 729:03 dbsrv9
> 1306 root 4 -12 69664 68M 1800 S < 1.2 4.5 731:15 dbsrv9
> 1309 root 4 -12 69664 68M 1800 S < 1.2 4.5 731:15 dbsrv9
> 1303 root 4 -12 69664 68M 1800 S < 0.8 4.5 729:53 dbsrv9
>
> Output from pstree
>
> [srb@brookstone-cors srb]$ pstree -np | grep dbsrv
> |-dbsrv9(1289)---dbsrv9(1291)-+-dbsrv9(1292)
> | |-dbsrv9(1293)
> | |-dbsrv9(1294)
> | |-dbsrv9(1295)
> | |-dbsrv9(1296)
> | |-dbsrv9(1297)
> | |-dbsrv9(1298)
> | |-dbsrv9(1299)
> | |-dbsrv9(1300)
> | |-dbsrv9(1301)
> | |-dbsrv9(1302)
> | |-dbsrv9(1303)
> | |-dbsrv9(1304)
> | |-dbsrv9(1305)
> | |-dbsrv9(1306)
> | |-dbsrv9(1307)
> | |-dbsrv9(1308)
> | |-dbsrv9(1309)
> | |-dbsrv9(1310)
> | |-dbsrv9(1311)
> | |-dbsrv9(1312)
> | |-dbsrv9(1313)
> | |-dbsrv9(1314)
> | |-dbsrv9(1315)
> | |-dbsrv9(1316)
> | |-dbsrv9(1317)
> | |-dbsrv9(1318)
> | |-dbsrv9(1471)
> | `-dbsrv9(1472)
>
> Output from ps-elf :
>
> [srb@brookstone-cors srb]$ ps -elf | grep db
> 040 S root 1289 1 0 63 -12 - 214574 rt_sig Aug17 ?
> 00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1291 1289 0 63 -12 - 214574 schedu Aug17 ?
> 00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1292 1291 0 63 -12 - 214574 read_e Aug17 ?
> 00:00:05 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1293 1291 0 63 -12 - 214574 schedu Aug17 ?
> 00:01:34 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1294 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:08:54 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1295 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:11:02 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1296 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:10:09 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1297 1291 2 67 -12 - 214574 rt_sig Aug17 ?
> 12:12:38 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1298 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:13:42 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1299 1291 2 63 -12 - 214574 rt_sig Aug17 ?
> 12:15:31 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 R root 1300 1291 2 63 -12 - 214574 - Aug17 ?
> 12:06:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1301 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:16:31 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1302 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:12:10 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1303 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:09:55 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1304 1291 2 68 -12 - 214574 rt_sig Aug17 ?
> 12:09:05 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1305 1291 0 65 -12 - 214574 rt_sig Aug17 ?
> 01:28:34 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1306 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1307 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:14:01 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1308 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 13:47:35 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1309 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1310 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:11:04 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1311 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:10:36 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1312 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:10:19 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1313 1291 2 64 -12 - 214574 rt_sig Aug17 ?
> 12:09:35 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1314 1291 0 63 -12 - 214574 semop Aug17 ?
> 00:03:12 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1315 1291 0 63 -12 - 214574 schedu Aug17 ?
> 00:00:04 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 R root 1316 1291 63 86 1 - 214574 - Aug17 ?
> 15-05:03:27 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti
> 0 -ud -x tcpip{Serv
> 040 S root 1317 1291 0 63 -12 - 214574 schedu Aug17 ?
> 00:11:15 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1318 1291 0 63 -12 - 214574 schedu Aug17 ?
> 00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 040 S root 1471 1291 0 63 -12 - 214574 schedu Aug17 ?
> 00:00:00 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 140 S root 1472 1291 0 65 -12 - 214574 rt_sig Aug17 ?
> 00:27:38 /usr/local/sybase/SYBSsa9/bin/dbsrv9 -gp 8192 -c 800M -ti 0 -ud -x
> tcpip{ServerP
> 000 R srb 4456 4300 0 76 0 - 435 - 10:34 pts/0
> 00:00:00 grep db
>
> I hope this helps.
>
> Steve
>
> "Mark Culp" <reply_to_newsgroups_only_please_nospam_mark.culp@iAnywhere.com>
> wrote in message news:4120EA52.3DE2F212@iAnywhere.com...
> > You can use dbconsole or SybaseCentral to find out what queries are
> running on
> > the
> > engine. This should show you what query is causing the thread to consume
> > process
> > time.
> >
> > If the above doesn't help, then you could run a strace on the offending
> thread
> > and post a snippet. A process/thread listing ('ps -elf | grep db') with
> an
> > indication of which process/thread is the offending one would also be
> useful
> > (i.e. we can get an idea of which thread within the engine is consuming
> CPU
> > since the engine always starts its threads in the same order).
> > --
> > Mark Culp
> > ASA Development
> > -------------------------------------------------------------------------
> > ** Whitepapers, TechDocs, bug fixes are all available through the **
> > ** iAnywhere Developer Community at http://www.ianywhere.com/developer **
> > -------------------------------------------------------------------------
> >
> > Steve Burbrink wrote:
> > >
> > > I've installed all all update to OS and the dbsrv9.
> > > Red Hat : 2.4.9-e.43smp -
> > > Sybase ASA : 9.0.1 (1753)
> > >
> > > I no longer have a single thread utilizing 99% CPU, but I now have a
> dbsrv9
> > > thread which has gone from 15% to 65% CPU utilization over a period of 2
> > > weeks.
> > >
> > > This is a 3.0GHZ Zeon machine, 1.5 GB RAM, a database which contains
> less
> > > than 50,000 records.
> > >
> > > How can I tell what the thread is doing?
> > >
> > > Steve
> > >
> > > "Steve Burbrink" <sywalters@hotmail.com> wrote in message
> > > news:41013867$1@forums-2-dub...
> > > > Thanks for the insight....
> > > > But... How can I get details on what a specific dbsrv9 thread is
> doing?
> > > >
> > > > Are they handling client connections?
> > > >
> > > > "Greg Fenton" <greg.fenton_NOSPAM_@ianywhere.com> wrote in message
> > > > news:41012676$1@forums-1-dub...
> > > > > Bruce Hay wrote:
> > > > > >
> > > > > > The event will re-schedule itself once it completes, so it will
> fire
> > > > less
> > > > > > frequently. For example, if it requires 7 seconds to complete, it
> will
> > > > > > execute every 10 seconds instead of every 5.
> > > > > >
> > > > >
> > > > > Thanks Bruce! I stand corrected. ASA is indeed "smarter than the
> > > > > average cron"! :-)
> > > > >
> > > > > greg.fenton
> > > > > --
> > > > > Greg Fenton
> > > > > Consultant, Solution Services, iAnywhere Solutions
> > > > > --------
> > > > > Visit the iAnywhere Solutions Developer Community
> > > > > Whitepapers, TechDocs, Downloads
> > > > > http://www.ianywhere.com/developer/
> > > >
> > > >