Hi all,
Just FYI that I have solved the nasty problem with X server crashing
once it consumed all available memory on the client.
I just added those lines at the beginning of the "startx" startup
script.
XMEM_RESERVE=2
MEMFREE=`grep MemFree /proc/meminfo | awk '{print $2}'`
Hi all,
Just FYI that I have solved the nasty problem with X server crashing
once it consumed all available memory on the client.
I just added those lines at the beginning of the startx startup script.
XMEM_RESERVE=2
MEMFREE=`grep MemFree /proc/meminfo | awk '{print $2}'`
XMEM=$(($MEMFREE
Wow!
A few months ago, I submitted a bug report to X.org to get them to add
an option to limit the amount of ram the Xserver would attempt to allocate.
Your solution is a totally different way to handle the problem, and from
the looks of it, it seems like it should work just fine. That is,
Jim, Jason,
I have done some more testing and here are the results:
- visiting some web pages in firefox (like the one Jason mentioned)
results in X consuming much more memory (50% in my case - I have 256Mb
on clients)
This memory is immediately released once you close firefox. I assume
this is
Ondrej,
Your observations of Firefox and X.org are spot on.
When you quit from firefox, the Xserver will release all of the memory
From the X.org guys that i've talked to about this, they say it's all
firefox's fault, because the Xserver doesn't know whether firefox is
still needing those
Jim,
Honestly, I do not care that much about firefox - as long as the memory
can be freed by occasionaly restarting it - I am fine.
What I am worried of is the second case - when using gpdf-like apps your
only chance for survival is to close the whole session and restart X
sooner than your
Hi Ondrej,
On Tue, 1 Nov 2005, Ondrej Valousek wrote:
I have done some more testing and here are the results:
Thanks very much for doing that work and for summarizing your findings for
us! And thanks to Jim for trying to pursue it with some of the developers
that might be able to do
Hi James,
On Sat, 20 Aug 2005, [EMAIL PROTECTED] wrote:
this mostly (all?) describes exactly the problem:
firefox uses thin client ram to render the sites images until it fails.
I have 300 photos in 'gallery-1.4' for 2005. Every standalone machine can
slideshow them, every thin client crashes
Hi all,
On Mon, 22 Aug 2005, Jason Maas wrote:
Does anyone know how to see the kernel log on an LTSP client?
I do! (Yes, I realize that I'm replying to myself. I finally got
motivated enough to try things.)
On our Debian unstable LTSP server I just copied the /bin/dmesg binary
to /bin
Jason,
There's just no getting around the fact that the Xserver is going to
consume memory. And for the most part, it's not X's fault, it's the
applications. the Xserver allocates memory on the apps behalf, and most
apps don't tell the Xserver to release the memory when it is done with
it.
So,
Hi Jim,
On Mon, 22 Aug 2005, Jim McQuillan wrote:
There's just no getting around the fact that the Xserver is going to
consume memory. And for the most part, it's not X's fault, it's the
applications. the Xserver allocates memory on the apps behalf, and most
apps don't tell the Xserver to
Jason,
I don't have any solid formula for setting the size of the swapfile.
I've found that just going with 64mb of swap has solved any problems
that I've encountered.
As for all situations, i'm sure there's a point where you could run
out of ram, even with 64mb of ram and 64mb of swap.
Jim.
Hi James,
On Fri, 19 Aug 2005, [EMAIL PROTECTED] wrote:
I can show you a site that will crash ltsp + firefox with 256M ram on
client, reliably, repeatably, and at the same point every time.
Ooo...tell me more! I was actually going to post to the list about a
problem we've had which sounds
Joe Baker wrote:
Jason Maas wrote:
Hi James,
On Fri, 19 Aug 2005, [EMAIL PROTECTED] wrote:
I can show you a site that will crash ltsp + firefox with 256M ram
on client, reliably, repeatably, and at the same point every time.
Problem description
---
The problem
Jason,
Turning on the NFS swap would be great to troubleshoot the problem,
and maybe even good final solution.
Btw, I checked out the dm.org website. Way to go! Looks like a great
organization -- and you use LTSP!
bob
On 8/19/05, Jason Maas [EMAIL PROTECTED] wrote:
Hi James,
On Fri, 19
:17:52 -0500
From: Joe Baker [EMAIL PROTECTED]
To: Jason Maas [EMAIL PROTECTED]
Subject: Re: [Ltsp-discuss] Client RAM requirements X crashing
Jason Maas wrote:
Hi James,
On Fri, 19 Aug 2005, [EMAIL PROTECTED] wrote:
I can show you a site that will crash ltsp + firefox with 256M ram on
client
Hi Joe,
On Fri, 19 Aug 2005, Joe Baker wrote:
I loaded up the page with Firefox on a thin client with 64 Meg of ram and 64
meg of Swap space over NFS. I usually never see the swap space used. In
this case I did see 19 megs of swap space used (the free command will
report the memory usage
Hi Joe,
On Fri, 19 Aug 2005, Joe Baker wrote:
The problem is with the web site design. Those bozos are putting _HUGE_
images on the page, then adjusting the size of the image down with the
image property tags in the HTML code.
I don't deny that the web page is hideous (and we have nothing
Hi Bob,
On Fri, 19 Aug 2005, bob greatguy wrote:
Turning on the NFS swap would be great to troubleshoot the problem,
and maybe even good final solution.
Thanks for the tip, I'll try it out.
Btw, I checked out the dm.org website. Way to go! Looks like a great
organization -- and you use
19 matches
Mail list logo
