I may also add that if you run KSM (Kernel Same page Merging) on the server side, it may dramatically improve your RAM consumption, since all clients use the same programs, and thus could share many pages. However, i know that ksm runs fine on fedora (12), but I'm not sure if it has been ported to ubuntu/debian/other systems. Please also note that KSM can use quite a lot of cpu (but if you don't give him time, it will just not merge page anymore and wait its turn, not lock your system).
Frederic. ----- "Scott Balneaves" <sbaln...@legalaid.mb.ca> a écrit : > On Wed, Dec 16, 2009 at 10:44:45AM -0500, Stéphane Graber wrote: > > Scott Balneaves wrote: > > > On Wed, Dec 16, 2009 at 02:33:39PM +0000, Evan Ingram wrote: > > >> hi > > >> > > >> i've seen various numbers quoted for ram requirements on an ltsp > server; > > >> "ranging from 256Mb + 32Mb per client to 1024Mb + 64Mb per > client." > > >> > > >> what are peoples findings in the real world? i need to spec up a > server > > >> for a school implementation of about 64 workstations, so needs > to > > >> perform usual web/office/multimedia tasks. > > > > > > What we officially recommend in the upstream documentation is: > > > > > > 256 + (192 * users) MB > > > > > > So, for 64 users, you'd be wanting a s server with at least: > > > > > > 256 + (192 * 64) ~= 12 gigs of ram. > > > > I guess we'll need to change that a bit in the doc then ;) > > I had up to 70 users on a single QuadCore server with 8GB of RAM and > > > there still was a Gig or so of free memory. > > Well, sure, there's always special cases. I mean, if you have people > using > nothing but mutt and vi in an xterm, one server may potentially serve > well over > 150 users. :) > > > I guess the above calculation is correct if your run everything > > (including firefox) on the application server and have your users do > > > very different activities. > > IIRC, we came up with that figure by having evolution, firefox, and > openoffice > opened simultaneously. I've always maintained LTSP server sizing's > more of a > black art than anything. Our usual response in the channel to people > who ask > "How much ram?" is "what do you want to run?" > > > On some of the very big deployments I have here, a user usually uses > > > less than 80MB of RAM on a non-loaded server (35 users when designed > for > > 100 or so). > > > > So, at least for Ubuntu Karmic, I'd say it's more like: > > 512MB (to take the recommendation from Ubuntu) + (80 * users) MB > > I've got one server with about 40 people. Typical usage for these > people would > be 2-3 firefox windows, thunderbird, and openoffice opened > simultaneously. > I've got 8 gigs of ram in it, and every once it a while it touches > swap. But > not often. > > > And if firefox isn't local, I'd probably make that 80 a 120 as it's > > > eating a lot of memory. > > Right, localapps will change your memory requirements drastically. > > > > Practically speaking, from a load averaging perspective, you'd do > better to buy > > > 2 servers, and split the load between them. A nice quad core with > 8 gigs of > > > ram isn't that expensive, and that will comfortably handle 32 > users. > > > > Splitting load across servers is always a good idea, that will also > let > > you afford having one server done for a while in case of emergency. > > Yep! > > Scott > > -- > Scott L. Balneaves | The human race has one really effective weapon, > Systems Department | and that is laughter. > Legal Aid Manitoba | -- Mark Twain > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _____________________________________________________________________ > 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 ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _____________________________________________________________________ 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
