Hi,

plz ignore multiple mesg. :

OS : Sun OS 10, sparc,

I am having user level program -- Network,Multithreaded,i/o intenesive
- file read/write

It works fine upto few hours and after that (under the almost same
load) it tries to eat
excessive cpu (checked using top) (tend to 100%, my sysadmin kills the
process when it access more than 90% cpu)

this is not repeatable, !

how to find the worng stuff ( i am having code- written in C (no C+
+),dbx,gdb,strace)?

is there any checklist to avoid this type of thing ? ( or better what
are the ways to write the code that will consume cpu badly ?)

application log is collected and running the simillar activities not
showing memory leaks,
any debugging - code analysis tool for this ?

should i ask my admin to allow to eat cpu and dumping core. ?

any way to force running process to dump core. ? (instead of kill -9
pid )



--Raxit Sheth

[ Post a follow-up to this message ]

Sheth Raxit wrote:
> OS : Sun OS 10, sparc,
>
> I am having user level program -- Network,Multithreaded,i/o intenesive
> - file read/write
>
> It works fine upto few hours and after that (under the almost same
> load) it tries to eat
> excessive cpu (checked using top) (tend to 100%, my sysadmin kills the
> process when it access more than 90% cpu)
>
> this is not repeatable, !
>
> how to find the worng stuff ( i am having code- written in C (no C+
> +),dbx,gdb,strace)?
>
> is there any checklist to avoid this type of thing ?

Try to avoid writing software with bugs in it.  :-)

> application log is collected and running the simillar activities not
> showing memory leaks,
> any debugging - code analysis tool for this ?

One easy method is to run "truss -p" against the running process.  It
doesn't tell you everything, but if you see what system calls a process
is making, in some cases that will give you an insight.  It will probably
be doing one system call (or a short sequence of them) over and over
and over again.

If you want more information, you might try adding the "-u" option
as well; that should give you user function calls as well as system
calls.  I haven't tried using it myself, so I can't give details
about it.

> any way to force running process to dump core. ? (instead of kill -9
> pid )

Could you attach a debugger to the process while it's running?

- Logan

[ Post a follow-up to this message ]

On Mar 13, 2:54 am, "Sheth Raxit" <raxitsheth2...@yahoo.co.in> wrote:
> Hi,
>
> plz ignore multiple mesg. :
>
> OS : Sun OS 10, sparc,
>
> I am having user level program -- Network,Multithreaded,i/o intenesive
> - file read/write
>
> It works fine upto few hours and after that (under the almost same
> load) it tries to eat
> excessive cpu (checked using top) (tend to 100%, my sysadmin kills the
> process when it access more than 90% cpu)
>
> this is not repeatable, !
>
> how to find the worng stuff ( i am having code- written in C (no C+
> +),dbx,gdb,strace)?
>
> is there any checklist to avoid this type of thing ? ( or better what
> are the ways to write the code that will consume cpu badly ?)
>
> application log is collected and running the simillar activities not
> showing memory leaks,
> any debugging - code analysis tool for this ?
>
> should i ask my admin to allow to eat cpu and dumping core. ?
>
> any way to force running process to dump core. ? (instead of kill -9
> pid )
>
> --Raxit Sheth


How about this...

A long time ago I wrote a program that performed very long running
numerical computations that took weeks. In order to find out how the
program was doing (how much progress it was making) without having it
write partial results to disk, this is what I did. Every once in a
while, I sent an interrupt signal to the running process which
proceeding to "find me" (I was obviously at the terminal which had the
most recent activity).

What I suggest is that a the entrance of every function you have a
global variable that says: "I am at buggy_funtion()", "I am at
long_running_function()", etc: some sort of poor man's program
counter.

-Ramon

[ Post a follow-up to this message ]

On Mar 13, 3:54 pm, "Sheth Raxit" <raxitsheth2...@yahoo.co.in> wrote:
> Hi,
>
> plz ignore multiple mesg. :
>
> OS : Sun OS 10, sparc,
>
> I am having user level program -- Network,Multithreaded,i/o intenesive
> - file read/write
>
> It works fine upto few hours and after that (under the almost same
> load) it tries to eat
> excessive cpu (checked using top) (tend to 100%, my sysadmin kills the
> process when it access more than 90% cpu)
The sysadmin is a person or program?
>
> this is not repeatable, !
>
> how to find the worng stuff ( i am having code- written in C (no C+
> +),dbx,gdb,strace)?
>
> is there any checklist to avoid this type of thing ? ( or better what
> are the ways to write the code that will consume cpu badly ?)
A simple while loop can cause such high percentage in CPU usage. So,
it is hard to tell which part is wrong. A possible approach is to
attach your debugger when you see the abnormal CPU usage. This
requires your abnormal behavior last for some time to allow you do the
attach action. If the high percentage is just a peak, oh, I don't know
how to do.
>
> application log is collected and running the simillar activities not
> showing memory leaks,
> any debugging - code analysis tool for this ?
>
> should i ask my admin to allow to eat cpu and dumping core. ?
>
> any way to force running process to dump core. ? (instead of kill -9
> pid )
>
> --Raxit Sheth

[ Post a follow-up to this message ]

On Mar 14, 7:39 am, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> Sheth Raxit wrote: 
> 
> 
> 
> 
> 
>
> Try to avoid writing software with bugs in it.  :-)
I am eager to know how ?  Is there any Frequently Known Practice that
cause cpu hungry program ?
 
>
> One easy method is to run "truss -p" against the running process.  It
> doesn't tell you everything, but if you see what system calls a process
> is making, in some cases that will give you an insight.  It will probably
> be doing one system call (or a short sequence of them) over and over
> and over again.
>
> If you want more information, you might try adding the "-u" option
> as well; that should give you user function calls as well as system
> calls.  I haven't tried using it myself, so I can't give details
> about it.
> 
I am able to get this 'gcore'[vbcol=seagreen]
>
> Could you attach a debugger to the process while it's running?
yes but i doubt how gdb/dbx is helpful here ?

>
>    - Logan- Hide quoted text -
>
> - Show quoted text -

--Raxit

[ Post a follow-up to this message ]

On Mar 14, 9:25 am, "Bin Chen" <binary.c...@gmail.com> wrote:
> On Mar 13, 3:54 pm, "Sheth Raxit" <raxitsheth2...@yahoo.co.in> wrote:> Hi,
> 
> 
> 
> 
>
> The sysadmin is a person or program?
program !
> 
> 
> 
>
> A simple while loop can cause such high percentage in CPU usage. So,
> it is hard to tell which part is wrong. A possible approach is to
yes,
> attach your debugger when you see the abnormal CPU usage. This
> requires your abnormal behavior last for some time to allow you do the
> attach action. If the high percentage is just a peak, oh, I don't know
how to make sure the high percentage is just a peak, because the
%figure is nearer to 100% !
> how to do.
>
>
>
>
> 
> 
> 
> 
>
> - Show quoted text -

--Raxit

[ Post a follow-up to this message ]

On Mar 14, 2:32 pm, "Sheth Raxit" <raxitsheth2...@yahoo.co.in> wrote:
> On Mar 14, 7:39 am, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> 
> 
> 
> 
> 
> 
> 
>
> I am eager to know how ?  Is there any Frequently Known Practice that
> cause cpu hungry program ?
>
>
> 
> 
> 
> 
>
> I am able to get this 'gcore'
> 
>
> yes but i doubt how gdb/dbx is helpful here ?
The attach will make the attached process to be in stop state. Then
you can get the point where the program is running in the moment you
do the attaching. Even you can get a backtrace.

I always do such in Linux with gdb.
>
>
> 
> 
>
> --Raxit

[ Post a follow-up to this message ]

Sheth Raxit wrote:
> On Mar 14, 7:39 am, Logan Shaw <lshaw-use...@austin.rr.com> wrote: 
[vbcol=seagreen] 
[vbcol=seagreen]
> I am eager to know how ?  Is there any Frequently Known Practice that
> cause cpu hungry program ?

1.  Infinite loops.
2.  Polling for events when you should be doing a blocking wait.
 
> yes but i doubt how gdb/dbx is helpful here ?

As someone else said, you can see what section of your code is
using the CPU.  That helps you know where to look for bugs.  Seeing
a stack trace helps you know how you get there, which is often
useful as well.

- Logan

[ Post a follow-up to this message ]

Sheth Raxit wrote:
> On Mar 14, 7:39 am, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> 
>
> I am eager to know how ?  Is there any Frequently Known Practice that
> cause cpu hungry program ?
>
A common cause is a loop that waits on something, often socket read or
accept, and that something goes away.  If the error return from the wait
isn't checked, the code repeats the failing call in a tight loop.

Truss or dtrace would show this.

--
Ian Collins.

[ Post a follow-up to this message ]