[OAUGNetDBA]-Re: Apps Tier performance issues

["Joseph Imbimbo" <joei@andrew.cmu.edu>]

Are there any backups occuring that might affect that node during that time?


-----Original Message-----
From: OAUG Net DBA listserver [mailto:OAUGNetDBA@oaug.com] On Behalf Of
Michael Porter
Sent: Thursday, August 21, 2008 8:27 AM
To: OAUG Net DBA listserver
Subject: [OAUGNetDBA]-Re: Apps Tier performance issues

When you are saying apps tier, you do mean that the db/CCM are on their own
node and the apache/forms are on another node right?  If so,  it would be
nice if you were able to use GRID/EM to evaluate that nodes performance and
what processes are consuming the most resources.  If you are single node,
then separating the db issues from the apps must be done;  but again,
GRID/EM would be helpful.  sar and top will only give guidance on whether
its I/O, mem, or CPU, an not really what processes, although watching top
can show a repeat offender that you might be able to trace to.  I would also
try and gather sar 24x7 and see what times show issues.  Is that time always
the same and who is doing what at that time.  Is this issue new, and if so
what has changed?  Can you have network sniffer analysis done to make sure
it is the EBS server(s) and not network latency issues?



>>> Cameron Hodge <Cameron.Hodge@minproc.com.au> 08/20/08 8:16 PM >>>
Hiya Everyone,

A little history first,

        We are a 24hr shop here (running 11.5.10.2) and our Brazilian users
are complaining of performance issues on a Friday.  Looking at some sar
metrics and top it seems the apps tier is pegging out on CPU for almost the
entire day. Now the Friday just gone (15th) , there where no performance
issues at all and I believe this was because Brazil had a holiday this day.

To me this indicates that the issue is with how our Brazilian users are
using the system, whether it be lots of concurrent requests or something
else I have yet to figure out.

We are a heavy projects  and OTL site and we have 2 JVM's on the apps
server.


** Question 1**
How do I go about tracing performance issues when the issue is how the users
are using the system? Its come up as a board report and now its up to me to
come up with a solution, which may be a bit more difficult than just tuning
a sql query.

** Question 2**
Is there any way I can trace back from a top report? If I have  a PID can I
tack back to a Apps User?

-------------



Mem:  14398224k av, 13641044k used,  757180k free,       0k shrd,  539992k
buff
                   8060432k actv, 3635068k in_d,  244492k in_c
Swap: 15358132k av,       0k used, 15358132k free                 9332260k
cached
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
  466 applprod  25   0  921M 921M  7256 R    24.2  6.5 478:44   1 java
27191 applprod  25   0  880M 880M  7300 R    23.8  6.2 499:48   3 java
24819 applprod  25   0  921M 921M  7256 R    23.6  6.5 504:24   2 java
13572 applprod  21   0 17152  16M  5192 D     2.4  0.1   0:00   3 ar60run
 8056 applprod  15   0 32700  31M  8808 S     0.9  0.2   0:01   3 f60webmx

-------------

Thanks in advance.



______________________________________________________________________
This email is intended only for the person to which it is addressed and may
contain confidential or legally privileged material. Any dissemination or
other use of or taking of any action in reliance upon the content of this
email by persons other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the email from
any computer. Opinions and other information in this email that do not
relate to the business of my employer are not given nor endorsed by it.
Unencrypted email is not secure and may not be authentic. If you have any
doubts as to the contents please telephone to confirm. GRD Limited and its
related entities accept no responsibility for changes made to this email or
its attachments after transmission from GRD Limited and its related entities
and do not guarantee that this email or attachments are virus or error free.
If you do not wish to receive further emails from us, please forward this
email to unsubscribe@grd.com.au.

______________________________________________________________________

#############################################################
This message is sent to you because you are subscribed to the mailing list
<OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com> To switch to the FEED
mode, send any message to <OAUGNetDBA-feed@oaug.com> To switch to the DIGEST
mode, E-mail to <OAUGNetDBA-digest@oaug.com> To switch to the INDEX mode,
E-mail to <OAUGNetDBA-index@oaug.com> Send administrative queries to
<OAUGNetDBA-request@oaug.com>



#############################################################
This message is sent to you because you are subscribed to the mailing list
<OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com> To switch to the FEED
mode, send any message to <OAUGNetDBA-feed@oaug.com> To switch to the DIGEST
mode, E-mail to <OAUGNetDBA-digest@oaug.com> To switch to the INDEX mode,
E-mail to <OAUGNetDBA-index@oaug.com> Send administrative queries to
<OAUGNetDBA-request@oaug.com>




#############################################################
This message is sent to you because you are subscribed to the mailing list <OAUGNetDBA@oaug.com>.
To unsubscribe, E-mail to: <OAUGNetDBA-off@oaug.com>
To switch to the FEED mode, send any message to <OAUGNetDBA-feed@oaug.com>
To switch to the DIGEST mode, E-mail to <OAUGNetDBA-digest@oaug.com>
To switch to the INDEX mode, E-mail to <OAUGNetDBA-index@oaug.com>
Send administrative queries to  <OAUGNetDBA-request@oaug.com>