Re: Stress test in ltsp
Hi JL Redrejo,
since you are plenty of ram and it looks like you don't have much trouble with
CPU I strongly recommend you using XEN with ltsp servers, for several
reasons:
1.- By separating the base system+ltsp , the desktop and the storage unit, in
3 differen virtual machines, you get a better maintenance aproach.
2.- You can update the desktop using debian edu without worrying about ltsp
3.- you can give the chance in the future to teachers to have web apps or
other services in the same server
4.- Yoy can move the storage unit to another server in the future if it is
necesary
5.- You can use more than one distro in the classroom. (or more than one
version of a distro) by placing anothe virtual machine. Sometimes computer
labs are used for different purposes.
6.- If your ltsp or base system changes (you go for ltsp 5 or 6 :)), you just
have to install another virtual machine and erase the old one, instead of
updating the one you have with the desktop or the storage unit on it. When
you have thousands of servers, this is much easier, you already know that.
7.- You can control ram and disk assignment to each system/service easily. You
can also get to different desktops through different networks.
For example, since the server is always on, you can place two different
desktops, one for kids and another one for teachers (or other kids) in the
same machine. They can access to them simultaneously without interferences.
I've always imagined the ltsp server placed on the school's cpd. It is utopic
yet because of bandwith problems but it is the idea: ltsp as a desktop
server, treated like any other central service.
Our experience with debian or centos + xen + ltsp is satisfactory, if you have
enough ram.
Bye and good luck. Big ltsp deployments in Extremadura will make a difference
so other spanish regions will use it.
El Thursday 17 April 2008 08:40:41 José L. Redrejo Rodríguez escribió:
> El mié, 16-04-2008 a las 14:42 -0700, vagrant@freegeek.org escribió:
> > On Wed, Apr 16, 2008 at 07:35:28PM +0200, José L. Redrejo Rodríguez wrote:
> > > In the last two weeks I've been doing some stress tests in the
> > > classrooms where I'm using ltsp, and I'd like to share the results and
> > > my conclusions.
> >
> > ...snip...
> >
> > > When using a 1 Gbps port in the switch to connect the server to the
> > > thin clients:
> > > - THere was some 98 Mbps NFS peaks, and some 124 ssh peaks, but they
> > > didn't last in time. All the clients started, no one was stalled. The
> > > starting time was reduced from 1'40" to 45" with the Open Office
> > > application running.
> > > - There was a ¿funny? result: the Xeon machine raised its CPU use to
> > > 100% when Openoffice started, with the Quad Core the CPU didn't raise
> > > more than 20%. Because of it, when using the Xeon server some of the
> > > clients where stalled for several seconds when starting X. Anyway, the
> > > starting time was about 5" less when using the Xeon for the clients
> > > that didn't stall.
> > >
> > > Conclusions:
> >
> > ...snip...
> >
> > > - The Xeon server seems to behave better in network use, but worse when
> > > starting big desktop applications with a lot of graphics.
> > > - RAM is not very important. The use of RAM was never more than 2
> > > Gbytes, remaining more than 1,8 Gbytes of not used RAM.
> > > - When there's no concurrency, both the Xeon and the Quad Core have not
> > > CPU problems, less than 5% starting OpenOffice (even if some other
> > > instances are already started), but when there is concurrency, the Xeon
> > > server behaves much worse. I don't know the reasons and would like to
> > > know any opinion.
> >
> > i'm wondering if there are differences in the on-board sata that is
> > causing a disk i/o issue... could try "dstat", which can report on
> > various types of i/o...
>
> Yes, it could be informative
>
> > could also copy the server's /opt/ltsp to a tmpfs and turn off the
> > server's swap, and see if that makes a difference in performance, as the
> > client OS will be loading from the server's ram.
>
> That's a very good idea. I'll try it today
>
> > i'd also be curious to see the performance using an i386 machine rather
> > than amd64, or the same servers with an i386 install of debian.
>
> mmm, do you think that using a -bigmem i386 kernel might have better
> perfomance than using an amd64, with 4-8 Gbytes of RAM?
> Theorically, memory pagination with -bigmem is much worse...
> Using i386 would make life easier with java and flash plugins, but I
> discarded it giving preference to perfomance.
>
> Regards.
--
Agustín Benito Bethencourt
Director de Ejerccios Resueltos SLU
www.grupocpd.com
http://toscalix.blogspot.com
http://abenitobethencourt.blogspot.com
Reply to: