Best way(s) to speed up lab?

[Harry Sweet]

Thanks for the suggestions.  

Is there any specific switch you recommend?

School starts next week, so for now I just have to work from memory.

We started last year with 2 gigs ram only.  Lagging would consistently
start after ~16 machines logged in.  I could see us hitting virtual memory at
the same time.  more memory solved that.

I'll collect data once I am running full out in a week or 2.  

Not all workstations would lag, either. But all apps on lagging boxes slow way down.  
The machines don't lock up, just get very droopy.
 I'll watch that this fall.

But Firefox seemed to always be an issue.  Especially since kids like to use it
to waste time playing on line video games, or watching videos.  

I should be able to make that a lot less interesting this year if I can get my firewall/whitelist working.


>>> Gavin McCullagh <gmccullagh at gmail.com> 08/29/09 8:37 PM >>>
Hi,

On Sat, 29 Aug 2009, Harry Sweet wrote:

> Which of these things would likely improve performance the most?

If you're having a serious, repeating lag problem, it sounds like it is
caused by a specific bottleneck.  You can optimise various things and you
might get lucky, but there's a reasonable chance you won't.  Ideally, you
need to pin down the cause.

Someone else has suggested cacti, I would have suggested munin though I'm
not sure there's much difference between them.  This will give you 5-minute
averaged details of various metrics of our server performance.  The trouble
is, if your lag only lasts 20-30 seconds, the data you need to see (eg
100Mbit/sec network usage) may be averaged out over the 5-minute intervals.

Could you describe the lag in a bit more detail, eg

 Is it always when everyone's using firefox?  
 Does it affect all thin clients at once, or each one at a time?
 Does it only affect those who are using firefox? 
 If someone is using OpenOffice instead is that affected?  
 Does it only affect firefox, eg are the GNOME menus frozen too?  
 Can you <alt><tab> to switch application?

More importantly, do you have any way to reproduce the problem?  I can
imagine you may not, but that makes it quite tough to work out whether the
problem is fixed or not.

> 2.  Lose the GUI on the server or at least drop Gnome for something faster

I presume you mean the GUI everyone uses on the thin clients.  That does
change a lot of the involved software, which might potentially contain your
problem.

> 3.  Run Firefox as a local app

If _firefox_ is lagging on the server.

> 4.  Get a gigabit switch to replace our 10 year old 100meg switch.

For what it's worth, in my work-place we don't use LTSP but we do use the
network pretty heavily and do various useful things like multicast (we have
about 70 switches).  It depends on your budget, but we generally buy
higher-end 100Mbit/sec switches with Gigabit uplinks, rather than cheap
gigabit switches.  I think that might suit you if you're on a budget and it
adds the benefit that even as many as 9 clients going at full tilt cannot
choke the uplink to the server.  As you are now (or in principal with all
gigabit clients), any one rogue client can choke the server.  Besides, I
doubt you have gigabit network cards in your clients.

Some switches can be configured to send snmp trap messages when an
interface's usage goes above a particular rate.

> 5.  Raid or SCSI disks

Always a possibility I guess.

> 6.. Something I haven't thought of .....

There have been reports of bad delays in the ext3 filesystem in certain
situations.  Some of this has been improved in the 2.6.30 linux kernel.
Something like that could be 

http://blog.gavinmc.com/?p=86

Gavin


-- 
edubuntu-users mailing list
edubuntu-users at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users