On Fri, 2004-07-23 at 06:28, Craig Ringer wrote:
> On Fri, 2004-07-23 at 20:07, sarab fadhil wrote:
> 
> [snip detailed system and user information]
> 
> Thanks for that info. It's really nice not to have to ask for it :-) and
> I'm sure it'll help the folks here figure out your problem.
> 
> > My problem is with the login which is slow,
> > it may take 10 minutes for all 32 students to login
> > together, of course some of them will login faster
> > than the others.
> 
> That's rather odd. Does a single, isolated user login on the system when
> it's otherwise unloaded take a more reasonable amount of time?
> 
> > However, once every one login the
> > system speed is acceptable, of course loading Star
> > Office is a slow even in a stand alone computer.
> 
> Loading the second and subsequent OpenOffice 1.1.2 instances on my LTSP
> server often takes only 2 or 3 seconds. The first one takes up to 10
> seconds, depending on whether or not the binaries are still cached in
> RAM. I had to turn off the splash screen because it sometimes only got
> time to half-finish drawing before the app's main window came up. So I
> wouldn't think that slow loading times are something to expect. The
> second and further OpenOffice/StartOffice instances should AFAIK load
> quite quickly if you have enough RAM and sufficient network bandwidth.
> 
> >  I am
> > using KDE as a user interface. Any advice of how to
> > speed up the system is appreciated.
> 
> The first step will probably be to start measuring what is taking the
> time. I'd recommend running 'vmstat 1 | tee /tmp/vmstat_log' while the
> users log in, as this provides some useful info on how hard the server
> is working. Additionally, I'd fire up gkrellm, a handy system monitor
> tool, to get a visual impression, and I'd have 'top' running to get
> real-time summaries of what programs are using the memory and CPU time.
> 
> It'd also be helpful to run 'free -m' before and after all the users log
> in (and a few times during, if you like) to get an impression of what
> sort of pressure the memory is under. 
> 
> If you could run
>     ps -eo pid,ppid,user,state,size,rss,wchan,cmd
> before, during and after user logins (and save the output somewhere)
> that'd be useful too, as that will among other things show if processes
> are in uninterruptable sleep (which is usually because they're waiting
> on disk I/O).
> 
> If you upload the vmstat output, the before and after 'free' output, ps
> output, and any other monitoring info you think could be handy to a web
> page and post your impressions about what the server seemed to be doing
> during the login process, that'd be handy. Uploading a copy of the
> output of 'dmesg' and a snippet of /var/log/messages that covers the
> duration
> Have you checked to make sure there isn't  of the user login process
> wouldn't hurt, either.
> 
> Of course, it's entirely possible that someone will be able to pop up
> here and say "yeah, I've seen this...." - but in case they can't, it'd
> probably be a good idea to collect this information. It's very hard to
> diagnose general performance problems without at least that information.
> 
> I should note that the use of a 7200rpm SATA disk, presumably one
> designed for general PC use, will not be helping your system performance
> at all. Even if each client's apps aren't trying to do much on it, those
> disks just aren't designed for heavy multitasking and it'll probably be
> thrashing like crazy. I run RAID 5 across 4 250GB SATA disks here, and
> the performance is pretty poor (but sufficient for our purposes, as it's
> mostly write-once read-occasionally archival data). AFAIK current
> 'consumer' disks and SATA chipsets don't support tagged command queuing,
> which means the disks have considerably less ability to reorder requests
> in a way that's more efficient for their physical layout, so they'll
> waste more time seeking - especially under heavy multi-user loads. There
> are now 10k RPM SATA disks with TCQ support available, but controller
> support for TCQ is far from universal and the disks are pricey. Still,
> they're cheaper (and according to StorageReview, often faster) than many
> SCSI disks.
> 
> Are your disks connected to a SATA RAID controller like a 3ware
> Escalade, to an add-in SATA card, or to SATA connectors on the
> motherboard? What chipset and SATA driver are you using?
> 
> The performance measures I've requested may help point out whether or
> not the issue you're seeing is disk related, memory related, or
> something else.
----
completely awesome mini-primer on system evaluation.

I am thankful to have this and will save it for the right moment.

Craig



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&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

Reply via email to