From: Himanshu Khona (himanshu.khona@patni.com)
Date: Wed Aug 27 2003 - 07:33:41 EDT
Hi all,
Thanks to Dr Thomas Blinn for his quick response/inputs.
>From the mail below i realise some lack of details from my end.
Here is what the actual problem is:
appear to have various issues that have a mixed cause and effect.
1) Sometimes batch processing is very slow yet on-line
transactions work fine.
2) Sometimes batch processing is very good yet on-line
transactions are slow.
3) Sometimes everything is poor.
Sometimes the box is low on memory, sometimes it appears to be low
or at least struggling with swapping.
Problems with the tape environment (Legato NSR) always cause sever
performance degradation.
Also it may be true that my approach may be wrong.
Also i don't intend to waste anyone's time. Just that there is some lack of
experience as far as performance analysis is concerned.
I hope the above problem statements help in getting me better response.
Also the enviroment is:
. Baan Version:
Baan IV c4 with SP7, Porting set 6.1c.05.02 on
Live server 6.1c.06 on development
. How they take back of Informix.
Ontape or onbar?
Onbar controlled by legato NSR
. Tru 64 alpha 2000 with 4gb RAM & 4 CPU.
. Informix 7.3.fc5 (database size 118GB ).
So the problem could lie at System, Baan or informix level. So probably it
would be daunting task.
Also the only need of asking the below questions was just to co-relate those
values against time & proccesses which are creating a resource crunch.
Regards
Himanshu
Man is a heroic bieng with his own happiness as
moral purpose of life, with productive achievement
as the noblest activity & reason as his only absolute
-----Original Message-----
From: Dr Thomas.Blinn@HP.com [mailto:tpb@doctor.zk3.dec.com]
Sent: Wednesday, August 27, 2003 4:23 PM
To: Himanshu Khona
Cc: Stephen. Kurel (E-mail)
Subject: Re: Performance analysis of tru 64 unix system alpha 2000 with
O.S.4.0D
You are going at this all backwards. You seem to be assuming that you
can gather some system statistics and then guess whether there is some
performance problem. You have never once indicated that you have ANY
kind of external indication that there is some problem that you need to
address.
For instance, high load averages at some point in time simply mean you
are presenting more work to the system than you have CPUs and other
resources (mostly CPU) to get done at that instant. That in and of
itself is NOT a problem; a problem is if users are complaining that
during times of high load average, the system is unresponsive, or if
the work that needs to get done in a given time window isn't getting
done because you lack the resources to do it.
Similarly, high swap in numbers don't necessarily point to a problem
that needs to be addressed -- it depends tremendously on the nature of
the workload presented to the system.
Do you have some EXTERNAL evidence that there is some problem with this
system that needs to be addressed? Because without that evidence (which
NONE of these statistics provide), you are off on a wild goose chase and
wasting your time and the time of your respondents.
Putting this another way, what problem are you trying to solve? This is
a system that was built maybe 4 or 5 years ago, it's outmoded technology,
you are running old (and no longer supported by the vendor) system software
and you've offered no hint about what the system is used for, and you are
off trying to figure out from system statistics if the system has some
kind of performance problem?
Tom
> Hi all,
>
> With reference to the above subject we have collected(some information we
> are yet to collect) virtual memory statics, process sub system, I/O
> sub-system.
> The enviroment if Tru 64 ver 4.0d with 4gb RAM & 4 CPU's of 533Mhz
> What i want to know from the list is the thresholds which i should look
for
> which if exxceeded points to performance problem.
>
> The headers are as follows:
>
> System Load:
> 14:46 up - days, 22:28, -- users, load average: a,b,c
>
> What should be the threshold values for the load averages?
>
> Process sub system;
> USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME
> COMMAND
>
> I would like to know what should be the thresholds of above fields which
> would point to the problem(like CPU, memory, SWAP etc)?
>
> Virtual Memory sub system:
>
> procs memory pages intr cpu
> r w u act free wire fault cow zero react pin pout in sy cs us
sy
> id
>
> AS above for this also i would like to know what should be the thresholds
of
> above fields which would point to the problem?
>
> I/O Sub-system:
>
> tty fd0 rz0 rz1 dk3 cpu
> tin tout bps tps bps tps bps tps bps tps us ni sy id
>
> AS above for this also i would like to know what should be the thresholds
of
> above fields which would point to the problem?
>
> Swap:
> Allocated space:
> In-use space:
> Free space:
>
> AS above for this also i would like to know what should be the thresholds
of
> above fields which would point to the problem?
> Thanks in advance. I shall summarize.
>
> Regards
> Himanshu
>
>
> Man is a heroic bieng with his own happiness as
> moral purpose of life, with productive achievement
> as the noblest activity & reason as his only absolute
>
>
> -----Original Message-----
> From: Himanshu Khona [mailto:himanshu.khona@patni.com]
> Sent: Wednesday, August 20, 2003 5:03 PM
> To: 'tru64-unix-managers@ornl.gov'
> Subject: Summary: Finding out current firmware level?
>
>
> Hi all,
>
> Thanks to so many people for quick response.
>
> The general consensus was:
> 1) consvar -g version.
> 2) grep Firmware /var/adm/messages
>
> Regards
> Himanshu
>
> Man is a heroic bieng with his own happiness as
> moral purpose of life, with productive achievement
> as the noblest activity & reason as his only absolute
>
>
> -----Original Message-----
> From: tru64-unix-managers-owner@ornl.gov
> [mailto:tru64-unix-managers-owner@ornl.gov]On Behalf Of Himanshu Khona
> Sent: Tuesday, August 19, 2003 5:39 PM
> To: tru64-unix-managers@ornl.gov
> Subject: Finding out current firmware level?
>
>
> Hi all,
>
> How can i know the current firmware level from the command prompt?
> Like we have eeprom command in solaris( i am sorry to mention solaris but
> that is what i have worked on till now).
>
> Thanks in advance
> Himanshu
>
> Man is a heroic bieng with his own happiness as
> moral purpose of life, with productive achievement
> as the noblest activity & reason as his only absolute
>
Tom
Dr. Thomas P. Blinn + Tru64 UNIX Software + Hewlett-Packard Company
Internet: tpb@zk3.dec.com, thomas.blinn@compaq.com, thomas.blinn@hp.com
110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
Alpha Hardware Platforms and I/O Phone: (603) 884-0646
ACM Member: tpblinn@acm.org PC@Home: tom@felines.mv.net
Worry kills more people than work because more people worry than work.
Keep your stick on the ice. -- Steve Smith ("Red Green")
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre@alpha.oac.ucla.edu
Yesterday it worked / Today it is not working / UNIX is like that
-- apologies to Margaret Segall
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:34 EDT