Hi,
my 2 euro cents of comment:
>> I was trying to compile the Kernel and it was crawling to ..
> Be prepared that kernel compiles will take several hours on this
machine.
> It's close to an hour on my dual SM71-SS20 with 256MB - with a SMALL
kernel
Affirmative, a compilation of a full SuSE-config'd kernel takes about 6..8
hours
on SS LX with 64MB RAM
About running KDE: I run KDE - it's a bit slow, but not painfully - on a
SS 5 with
_96_ MB RAM, on 64MB machines (otther SS5 and LX) it's just not quite
usable; so on
32MB machine go with the alternative window managers others on this list
have mentioned.
Thomas
"Ingo T. Storm" <[EMAIL PROTECTED]>
10.06.02 23:33
An: "suse sparc" <[EMAIL PROTECTED]>
Kopie:
Thema: Re: [suse-sparc] trying to compile 2.4.16 kernel on Sparc LX ..
> I was trying to compile the Kernel and it was crawling to ..
Be prepared that kernel compiles will take several hours on this machine.
It's close to an hour on my dual SM71-SS20 with 256MB - with a SMALL
kernel
with only the modules needed on a firewall. Please don't forget you are
running a beautiful machine - but it has the equivalent horsepower of an
early Pentium. You'll have to go UltraSparc if you want fast kernel
builds.
> Which utility should I use to really see what is going on with
> memory and swap allocation ? Tried vmstat but that's a bit cryptic to me
!
[root@e1k root]# vmstat 10 2
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 2788 14464 23096 15132 0 0 0 0 3 2 0 0
5
0 0 0 2788 14460 23096 15132 0 0 0 1 103 5 0 0
100
The important columns are:
"procs r" (unning): Number of processes that are ready to run. Shouldn't
be
over 2 (multiplied by #cpus) for a longer period.
"si/so": swapping in and out. Should be 0 most of the time or you are
short
of RAM (yes, there are exceptions, but not for regular use).
"cpu us"(er): percentage of time spent running your programs
"cpu sy"(stem): perc. time spent by kernel stuff. Shouldn't be over 10-20%
for extended periods of time, otherwise you probably have an I/O problem.
"cpu id"(le): the obvius. Shouldn't be over 5 percent, or you are wasting
electricity;-)
top isn't bad for a first glance either:
try "top i S" (i to ignore idle processes, so you only see the processes
that actually so s.th., S to show the cumulative time of a process and its
dead children. This is esp. nice to see how much "make" has been doing
with
all the processes it has spawned).
Sample during a build of wmakerconf on a SparcServer1000 with dual SM61,
64MB, kernel 2.2.x:
11:26pm up 5 days, 5:37, 3 users, load average: 1.04, 0.79, 0.39
41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 0.3% user, 2.2% system, 0.0% nice, 96.4% idle
CPU1 states: 95.1% user, 4.3% system, 0.0% nice, 0.0% idle
Mem: 60352K av, 58968K used, 1384K free, 12700K shrd, 17612K
buff
Swap: 264112K av, 3240K used, 260872K free 26428K
cached
PID USER PRI NI SIZE RSS SHARE STAT LC %CPU %MEM CTIME COMMAND
8401 root 3 0 1196 1196 964 R 0 2.9 1.9 0:19 top
10729 root 13 0 7896 7896 1900 R 1 99.2 13.0 0:06 cc1
read: 2CPUs, one at full load (cc1), one 96,4% idle, no memory shortage
(only 3240K swap in use).
Apart from that: Nick's guideline on what NOT to run look pretty good to
me.
And of course all my figures are estimates from my usage patterns and by
no
means scientifically based and proven. As usual, YMMV.
Ingo
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
