On 01/03/2012 12:49 PM, Lachele Foley (Lists) wrote: *snip* > I probably wasn't very clear that the only place I've found a solution > regarding having a session terminate suddenly and being booted back to > login had to do with that setting. I had ignored the setting because, > as you say, with 2+GB of RAM, it seemed unlikey that was the issue. > But, in desperation I tried it, and much to my surprise, one problem > (VMD) was fixed by altering it. So, somehow, it's having an effect, > though I don't think it should.
I think you're right with that. Unless you're having HARD-lock issues, X_RAMPERC probably isn't going to help much. But maybe it's at least a clue as to why it "fixed" VMD...just a guess, but maybe bad memory? Have you examined the logs? Cheers, Jordan --- > On Tue, Jan 3, 2012 at 3:09 PM, Jordan Erickson > <jerick...@logicalnetworking.net> wrote: >> Hi Lachele, >> >> I haven't had my hands in lts.conf for a little while but I think your >> perception of X_RAMPERC is a little off. >> >> You mentioned that "even setting X_RAMPERC to 20 didn't make the default >> Unity3D session work" - I would imagine not much at all would work if >> you only allow 20% of your memory to be allocated for the X server on >> the terminal! >> >> Check this out. I don't know if you've been posting here in the recent >> past so I apologize if I'm not seeing the context.. but I've dealt with >> X_RAMPERC a lot before regarding older issues with Firefox (pixmap >> cache....groan). >> >> You shouldn't even really worry about X_RAMPERC if you have 2GB+ memory >> on the terminal side, I would imagine. But if you want to make sure your >> entire session doesn't hard-lock because of you running out of memory, >> set it to 95 or something similar, so it will kill any offending >> application that might be gobbling up memory, before it takes the whole >> system down with it. >> >> >> ----- >> >> _X_RAMPERC_ >> default ´100´, Percentage of RAM for X server >> >> Some programs allocate a large amount of ram in the X.org server >> running on your thin client. Programs like *Firefox* and *Evince* >> can >> use up so much ram, that they eventually exhaust all your physical >> ram, and NBD swap, causing your thin client to crash. If you find >> your clients being booted back to a login prompt, or freezing up >> when viewing certain PDF´s or web pages, this may be the problem. >> >> The _X_RAMPERC_ variable stands for X RAM PERCent, and is a number >> between 0 and 100 that specifies how much of the free space on your >> thin client X.org is allowed to consume. You´ll generally want to >> set it at something lower than 100 percent, if you´re having >> problems. Experimentation has shown a value between 80 and 90 will >> usually keep the terminal alive. What will then happen is the >> program consuming the memory will die, as opposed to the thin >> client itself. If you´re having unexplained terminal problems, >> specifying: >> >> X_RAMPERC = 80 >> >> in your lts.conf file may improve things. >> ----- >> >> >> Again, I hope I'm not out of context and that this info helps. =) >> >> >> Cheers, >> Jordan >> >> >> >> >> On 01/03/2012 08:29 AM, Lachele Foley (Lists) wrote: >>> I'm really confused about why changing X_RAMPERC fixed one problem, >>> and if so, why it didn't fix another. >>> >>> The issue is that clients with less RAM won't need to have X_RAMPERC >>> set lower, but clients with more RAM will. There are other >>> differences, of course -- different hardware, different client image >>> (64 vs 32). But, it seems odd that a client with 1 GB of RAM can >>> handle something that a client with 2 or 4 GB can't. >>> >>> And, I'm not talking about a system that has other programs eating >>> memory. I mean (1) boot client, (2) log in, (3) start or start to use >>> program, (4) back to login immediately. On one machine (loaner, no >>> longer available for testing), this would cause it: (1) boot (2) log >>> in (3) open terminal (4) "ltsp-localapps xterm". I'm surprised that >>> opening a couple terminals could eat that much memory that quickly. I >>> didn't try resetting X_RAMPERC on that machine because I simply could >>> not believe that was the problem. I could open and run other programs >>> -- there were only a few that caused it. When they did, though, they >>> did so immediately or almost immediately. >>> >>> Most recently, the program VMD would cause crash-to-login if its >>> display window was moved from one monitor to the other. Again, this >>> is at fresh boot and login, and without having even loaded any files >>> into VMD. Oddly, running VMD as a localapp on the client worked fine >>> (and a lot faster). However, I finally decided to try lowering >>> X_RAMPERC, and, lo-and-behold, VMD stopped crashing when not run >>> locally. These clients have 4 GB and the server has 32. During these >>> tests, there was very little load on the server either. Right now, >>> with three different browsers, each with multiple windows, evince and >>> a handful of terminals running, that same client says it has 3.37 GB >>> of its 3.94 GB free (using "free"). I just opened VMD, and that >>> changed to 3.36 free. We also have several dual-monitor setups on >>> older equipment that handle this sort of thing just fine, and lots of >>> other stuff, all at once. >>> >>> So, even though setting X_RAMPERC fixed the VMD issue... I wonder if >>> the problem isn't really somewhere else. >>> >>> By the way, even setting X_RAMPERC to 20 didn't make the default >>> Unity3D session work. It still appears to accept a password, then >>> makes the theme music, then back to login. Other sessions (2D, XFCE, >>> LDXE, xterm) work fine. >>> >> >> >> -- >> Jordan Erickson (PGP: 0xDA470FF8) >> LNS: (707) 636-5678 - http://logicalnetworking.net >> >> >> ------------------------------------------------------------------------------ >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. Create >> new or port existing apps to sell to consumers worldwide. Explore the >> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >> http://p.sf.net/sfu/intel-appdev >> _____________________________________________________________________ >> 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 > > > -- Jordan Erickson (PGP: 0xDA470FF8) LNS: (707) 636-5678 - http://logicalnetworking.net ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _____________________________________________________________________ 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
