> > - *remove* the set priority_paging=1, and initially
> Ok, I removed this parameter, Do I need to keep the parameters below
> ?
>
> set cachefree=191514
> set lotsfree=95757
> set desfree=47878
> set minfree=23939
> set fastscan=95757
> set slowscan=9575
> set handspreadpages=95757
> set maxpgio=256
If you don't know the history of the /etc/system values
it's always better to just record them somewhere and start
from scratch. Dump them. If your bottleneck looks like
vm later you can tune them if needbe, but I doubt it
will be necessary.
I've not yet used gigabit, but here's what I'd do:
*make sure you have patch 1088513-06 (the ge driver patch)
installed* [probably doesn't help, but the important
thing is you're ruling out _known_ issues]
- check your /dev/tcp settings against the ge manual (you can
probably find it at http://docs.sun.com).
> It haves many errors...:
>
> module: ge instance: 0
> name: ge0 class: net
> drop 5486747
> ierrors 5486750
> inits 73
> ipackets 2697829779
> ipackets64 2697829779
> no_free_rx_desc 1
> rx_length_err 1
> rx_overflow 1
> no_tmds 0
> nocanput 33397
> nocarrier 5
The nocarrier errors are slightly concerning (unless you
happen to know that someone has pulled the cable out 5
times since it was last up). Generally indicates a physical
problem, although you're not getting any other physical
errors. If you suspect a physical problem>
- check the cable integrity
- test the interface with the SunVTS package (download
from Sun/SunSolve)
The nocanput errors mean there is no space upstream for
the ge driver to dump it's data. There's another /etc/system
tunable that may help:
* increase max streams queue depth
* to get rid of nocanput errors on hme1
set sq_max_size = 120
You can change it without rebooting by doing:
# adb -kw /dev/ksyms /dev/mem
physmem 138f33
sq_max_size/X
sq_max_size:
sq_max_size: 2
q_max_size?W 0x50
symbol not found
sq_max_size?W 0x50
sq_max_size: 0x2 = 0x50
sq_max_size/X
sq_max_size:
sq_max_size: 50
$q
Be cautious in setting this parameter however, it can easily
hang your box if you set it too high. Normally you see norcvbuf
at the same time, you're not here, I don't know why. Also you're
seeing a large number of ierrors/drops; again the other stats don't
indicate why. The netstat -sP tcp didn't contain anything interesting
- all looked fairly normal.
If the problem persists after the above, try graphing your
kstats for the interface (use the Perl kstats module and
rrdtool or something similar) - see if any of the parms
match up with your bandwidth peaks/memory/cpu usage.
Also, get familiar with where your kernel is busy
(vmstat, mpstat, iostat, busstat, and 'lockstat -AcwP -D 20 sleep 10'
[or similar])
That's the best I can come up with for now (like I say
I've never worked with ge...)
best of luck,
Mike
-- Michael Kiernan Onet.pl S.A. Krakow, Poland http://www.onet.pl/Received on Wed Oct 17 2001 - 00:31:59 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:02:47 MST