SUMMARY- One Slow SUN

From: Craig L. Gruneberg (clg@csph.psu.edu)
Date: Mon Feb 10 1997 - 08:38:40 CST


Sorry for the delay in generating this summary but other, more pressing
problems developed since I wrote the group seeking help.

My original plea was:

----- Begin Included Message -----

Subject: One Slow SUN

One of my networks consists of an Ultra 2, a 4-way Sparc 20, a
plain-jane 20 and a Sparc 5. All are running Solaris 2.5.1 except the
4-way.

The problem I am writing to you about concerns a marked performance hit
on the 4-way that occurs when the network traffic is high.

I notice the problem when I am doing remote dumps from the Ultra to
the plain-jane 20 which is where the tape drives are. The 4-way
just plain sloooooowwwwws way down as if some NFS operation has
total control on the box.

The strange thing is that the only difference I can find between the
4-way and the other clients ( besides being multi-processor ) is the OS
version. All NFS mounts are being done the same as in the other
clients, the 4-way is not being used any differently than the
plain-jane, etc.

Does anyone have any experience with this before I get involved in
some network troubleshooting?

thanks and will summarize,
-craig

----- End Included Message -----

Thanks to all that replied. Their reponses follow. I am still looking into
this problem and so far the only thing I have found that looks odd is when
I do a ping to the slow SUN using large packets while a ufsdump is going
on I get alot of packet loss (genepi is the slow SUN, monoz is running fine ):

{clg} dyz: ping -s genepi 8000
  ----genepi PING Statistics----
  21 packets transmitted, 11 packets received, 47% packet loss
  round-trip (ms) min/avg/max = 15/16/19

{clg} dyz: ping -s monoz 8000
  ----monoz PING Statistics----
  11 packets transmitted, 11 packets received, 0% packet loss
  round-trip (ms) min/avg/max = 15/18/25

The other interesting thing is in the number of packets reported as
transmitted. I let both pings run for 11 packets but the ping to genepi
reports 21.

I'll be upgrading the slow SUN to Solaris 2.5.1 soon so I'll see what things
look like after that.

Thanks for your assistance.

-craig

*****************************************************************
>From Gary.White@ramstein.af.mil Tue Feb 4 10:20:07 1997

  Sun advertises a marked improvement in NFS in Sol 2.5 over 2.4 and
  earlier versions. If you are NFS mounting something from this machine
  and accidentally tarring it back to the tape drive you will see marked
  difference between it and the others. Sun advertises a 30% increase in
  NFS speed with Sol 2.5.

  If you are using ufsdump then this is likely not your problem. If you
  are using tar you may be dumping files physically residing on the 4way
  to the tape.
*****************************************************************

*****************************************************************
>From Nate-Itkin@ptdcs2.intel.com Tue Feb 4 11:43:05 1997

  I have an open trouble call with Sun regarding ip performance between
  Solaris 2.5.X and SunOS 4.1.X. So far I have no workaround or
  resolution. I'll try to remember to give you the outcome, but you
  might want to ping me in a week or two in case I forget.
*****************************************************************

*****************************************************************
>From john@starinc.com Tue Feb 4 11:57:06 1997

  What is the OS on the 4-way SS20?

*******
My answer- Solaris 2.4, kernel patch 101945-42.
*******

>From john@starinc.com Tue Feb 4 12:46:35 1997

  That version is just fine.

  I guess at this point there isn't much else but start doing some
  network analyzing using netstat, nfsstat and possibly look into simple
  cpu and memory utilization using vmstat. A memory leak issue could
  cause the system to misbehave.

  Does this problem disappear after a reboot only to return sometime
  later?

  In any case, try a netstat -i to check collision rates. Do a nfsstat to
  check nfs and rpc services and check out vmstat -3 for cpu and memory
  utilization.

  Thats all I can think of for right now without being on site and such.

*****************************************************************
>From Sezgin.Askin@gantek.com.tr Tue Feb 4 15:26:29 1997

  Dear Craig,

  I did not hear anything about this problem but may be it is coming
  from the NFS versions.Solaris 2.5.1 is using NFS version 3 (I am not
  sure but I remember that NFS ver. 3 started with Solaris 2.5)And may
  be your 4-way machine can not support the speed of the version 3.NFS
  version 3 has got a performance about 25% better than ver. 2.All I
  can imagine about this problem is that probability.I hope It will be
  helpful.

*****************************************************************

*****************************************************************
>From fetrow@biostat.washington.edu Tue Feb 4 17:01:22 1997

   A 4-way SunOS 4.x machine is often slower than a 2-way SunOS machine
  due to lock conflicts; especially on I/O intensive operations. You might
  try pulling two of the CPU's!
*****************************************************************

*****************************************************************
>From peter.bestel@uniq.com.au Tue Feb 4 21:30:49 1997

  What version of the OS is the SS20 running? Does this behaviour
  happen any time the dumps are run, or only when the 'regular'
  time for dumps comes along?

  Assuming you're running Solaris 2.x:

  Check netstat -i for lots of collisions if you believe that it's
  the network. Also use nfsstat -c to look for nfs retransmits to a
  server.

  Are you out of CPU or out of disk ops? Use iostat -cx to check for
  wait times on disk and service times. vmstat to check other CPU /
  kernel state.

  Plain bad network performance shouldn't affect the box that much.
  Start using the tools to dig up some more info on the behaviour.

*****************************************************************
>From jacques.rall@za.eds.com Thu Feb 6 23:06:21 1997

  Are they running the same version of NFS?
*****************************************************************



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:45 CDT