On Wednesday 17 December 2003 17:02, Ragnar Wisløff wrote: > garry saddington skrev: > > <snip> > > >I have seen this symptom on my network. The black X on a grey background > > seems to be caused by the server being swamped by runaway processes or by > > too many requests for processor or disk read/writes, this causes a lock > > up and the client connection to the server gets broken and because the > > server is swamped KDM can't restart . Usually, if it is just too many > > users, when those users log off KDM will restart and present a log on > > screen. If there are runaway processes however, they stay runaway and KDM > > will refuse to start even when there are very few users. You need to be > > looking at 'top' when these things happen to diagnose the cause but I > > would hazard a guess that runaway processes are the main cause of these > > symptoms. Although your server spec. may be a little low for 50 > > concurrent heavy users (java and flash games, mozilla, openoffice etc.). > > The statistics show a top type load (not my favourite load measurement, > though) of between 10 and 20. The CPU utilisation show some cycles left > (almost never 0% idle) with user processes taking about 80% of the load. > The disk subsystem (SCSI, RAID 5/10k drives) as queried by vmstat (and > looking at io/bo,bi) is not very busy. I would consider numbers there at > about 5000+ to be high, but they're doing a few hundreds. The box hardly > ever swaps.
I see these types of load at the start of lessons when everyone is logging on. If it continued like this I would be forced to increase the server capacity. > > >I run about 90 terminals from three servers, each is a dual Athlon 2000+ > > with 1 gb ram. Most times this copes but at busy times swapping to disk > > gets too heavy and things clog up so i am just up-grading to 2 gb ram per > > server. As a rule of thumb, in a school environment I would recommend the > > following for your servers to have a comfortable time: > > > >One 2ghz+ processor per 15 potential concurrent users > >1gb ram per processor > >hard disk should be scsi with 64 bit access spinning at least 10k rpm > > Heh, specs are just soaring, arent't they :-) > > But I do agree that spreading the load across several servers is a good > idea. I have terrible experiences with dual Athlons, though. The > chipsets for the motherboards never became stable. Our supplier > mentioned that just about every single one of the machines they had sold > had been sent back. > > >At least this is what i would be comfortable with at my school. > > Yes, the problem is partly the user patterns at the schools :-/ > The kids love to play Java and Flash games, and it just creates floods > of packets. > > >So for your situation another server of dual processor and 2gb ram would > > make me comfortable, but then you would need a further /home server to > > prevent the need for syncing etc. > > We've considered that, but I have this nagging feeling it's a network > related problem, I just can't point at the cause of the problem. I > wonder if it's the NIC/driver that's not keeping up and packets get > dropped. > > If it's the server hardware like disks/CPU/RAM not keeping up, then why > would kdm report that it cannot open the display? This is what bugs me. The kdm process is running on the server and if the server is swamped it can't open another display. All things for me point to server under capacity. I know we hear of LTSP servers coping with loads of clients, but in schools those clients want it all and they want it now. We typically need much more raw power to cope with peak demand than in other situations. regards garry ps. thinking of adding a fourth server soon! > > >hope this has helped > > Thanks! ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
