Performance analysis of tru 64 unix system alpha 2000 with O.S.4.0D ..Some more details.

From: Himanshu Khona (himanshu.khona_at_patni.com)
Date: 08/27/03

  • Next message: James John - jrjame: "C2 Encryption"
    Date: Wed, 27 Aug 2003 17:03:41 +0530
    To: tru64-unix-managers@ornl.gov
    
    

    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.


  • Next message: James John - jrjame: "C2 Encryption"