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
