jones yeates wrote:
> >From the readings that top is showing the server is
under almost no
> load .16 ( if this was when there were some TC's connected to it).
> don't you post what the make/model number of your switch is.
>From what I can remember the switch is a BayStack, I don't know
what the model number is. It has 24 ports that are 10/100's and a
Cu Gigabit uplink.
> >From the error that Jperf is throwing you do not have Java
> your server. This is just about a must. So,, do an ' yum install
> then your Jperf will run without a hitch on your server.
yum install java doesn't work. You have to go to the site and download
I haven't done it yet, but I plan to.
Yesterday I had my server "heavy" day. Things worked at normal
speeds. I am not sure what happened last week. However the server was
extremely slow. I used the System Monitor and watched it all day.
Yesterday, when things were slow it was either: a lot of network usage
or CPU usage, but not both.
In the morning the students were on Window boxes using Flash and
Samba. I think some of them were working directly off of the server:
saving/executing. I think that might have slowed things down. I asked
them to copy the file onto their desktops and work from there and then
save it to their folders. It seemed to work a bit better.
Ah, now that will affect things in a big way. If you've already got a
lot of disk I/O going, that will certainly slow things down. In your
situation, I'd have a physically separate, dedicated file server with
hardware SATA RAID (level 5 or 10) and at least six spindles (hard disk
drives); the more spindles here, the better. Any time I do any heavy
disk I/O on my K12LTSP server here at home, it slows down the server.
Of course, my server has only a SATA RAID 1.
About five years ago, I had installed a K12LTSP server into a
25-station lab, using Pentium II's as EtherBooting thin clients. It
was a dual AMD Athlon MP, used twin 80GB EIDE disk drives, and had 4GB
DRAM. It was also one of the school's major file servers. The server
was not slow...but only because the DRAM caching was saving my butt
(the K12LTSP 2.12 of that day used way less DRAM). Today, I would
never try that.
During the afternoon (they were on a Linux box), there was no noticable
lag. I also asked the students to try to use Opera instead of
Firefox. They complained a bit but it was nice to see the CPU numbers
Have them try Konqueror as well. It takes wonderful advantage of
shared libraries (thus lower DRAM usage) and also will find/use the
Firefox plugins (Flash, etc.). Further, it comes with stock K12LTSP
and thus works with "yum update".