Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"Slow System" Problem

4 views
Skip to first unread message

Zev Berezin

unread,
May 14, 2003, 11:20:12 AM5/14/03
to

Hi All,

Tech Specs:
IDS: 7.31.UD5W5 - O.S: Solaris 6 - 10 CPU 248 MHZ

I have a situation where the OLTP system usually hums along
great but at times slows down drastically.
This can happen at any time of the day (so forget the crons).
It would be great to be able to pinpoint the sessions causing the
problem or to be able to track CPU usage by session.
At times I would kill the sessions where onstat -u showed the most
reads and/or writes but that wouldn't help.
Any help is greatly appreciated.

TIA,
Zev Berezin

Greg Mitchell

unread,
May 14, 2003, 1:52:56 PM5/14/03
to
Zev,

That's a tough one. First off, try using something like Peter
Schmidt's most_active1.sh script at www.peterschmidt.com to determine
which engine thread is doing the most I/O at the time.

After that you may want to use the onlog utility to review the log
entries to determine who/what is putting out a high transaction
volume.

Use the pid from the onstat -g ses <sessid> output from the script to
get the percentage physical cpu usage.

ps -o pcpu,comm -p <pid>

As to isolating the percent virtual cpu. I'm not certain how that can
be done. It must be a metric you have to activate like the wait
statistics.

Another thing to check is the onstat -g ntu and see if any of your
connections are looping. I've had some programs burn up virtual CPU
by not disconnecting properly and it showed up in the onstat -g ntu.

regards,

Greg Mitchell
Tecsys Inc.

Bill Dare

unread,
May 14, 2003, 1:43:38 PM5/14/03
to

Are you sure you are bottlenecked on CPU? Check sar when this happens to
make sure.

If that's the case, you can track the most active sessions by looking at
which ones show up on the active queue(onstat -g act) most often. That can
be a problem if you have a lot of users and several CPU virtual processors.
I've got a script I can send you that runs "onstat -g act -r 1" in the
background and then will output all sessions rstcb sorted by how often they
were on the active queue. It will then prompt you for the rstcb you want to
investigate and map it to the session and process. Let me know if you want
a copy.

Regards,
Bill Dare

Gustavo Tobares

unread,
May 15, 2003, 3:47:51 PM5/15/03
to

you check te output from onstat -m? see the checkpoint duration o some other
info in the .log file. (longs tx, etc.)

-----Mensaje original-----
De: Zev Berezin [mailto:ze...@bhphotovideo.com]
Enviado el: Miércoles, 14 de Mayo de 2003 12:20 p.m.
Para: inform...@iiug.org
Asunto: "Slow System" Problem

Gustavo Tobares

unread,
May 15, 2003, 3:49:21 PM5/15/03
to

Hi, can you tell me how can I detect the "looping connections" from te
onstat -ntu?

thank's

Gustavo Tobares
Administrador de Sistemas y DBA
Centro de Computos - Red Megatone
TE: 0342-4500972 - Fax: 0342-4500940

-----Mensaje original-----
De: Greg Mitchell [mailto:greg.m...@tecsys.com]
Enviado el: Miércoles, 14 de Mayo de 2003 02:53 p.m.
Para: inform...@iiug.org
Asunto: Re: "Slow System" Problem


Zev,

That's a tough one. First off, try using something like Peter
Schmidt's most_active1.sh script at www.peterschmidt.com to determine
which engine thread is doing the most I/O at the time.

After that you may want to use the onlog utility to review the log
entries to determine who/what is putting out a high transaction
volume.

Use the pid from the onstat -g ses <sessid> output from the script to
get the percentage physical cpu usage.

ps -o pcpu,comm -p <pid>

As to isolating the percent virtual cpu. I'm not certain how that can
be done. It must be a metric you have to activate like the wait
statistics.

Another thing to check is the onstat -g ntu and see if any of your
connections are looping. I've had some programs burn up virtual CPU
by not disconnecting properly and it showed up in the onstat -g ntu.

regards,

Greg Mitchell
Tecsys Inc.

On Wed, 14 May 2003 11:20:12 -0400, "Zev Berezin"
<ze...@bhphotovideo.com> wrote:

0 new messages