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=20000
MEMFREE=`grep MemFree /proc/meminfo | awk '{print $2}'`
XMEM=$(($MEMFREE - $XMEM_RESERVE))
echo "**** X sever limited to ${XMEM} kB RAM ****"
ulimit -v ${XMEM}
It did not solve the problem source, but at least X server (and users
whole session) survives.
It would be nice to see something like this in the next version of LTSP.
Happy new year!!
Ondrej
Jim McQuillan wrote:
>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 resources.
>
>I hear occasional rumours that there is (or will be) an option in X.org
>to limit how much ram can be allocated. Then, a well behaved app should
>be able to pay attention to the error returned from the allocation
>request, and deal with it properly, rather than crashing the Xserver.
>
>I'm at the Ubuntu dev conf, and we've got X.org guys and Firefox guys
>here, so i'll try to corner them, to see what we can do.
>
>Jim McQuillan
>[EMAIL PROTECTED]
>
>
>
>
>
>
>On Tue, 1 Nov 2005, Ondrej Valousek wrote:
>
>
>
>>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 a normal behaviour
>>- I tested several X servers connected via XDM to a logon box (RHEL 4,
>>Gnome) and used certain applications like gpdf (try to scroll up and down):
>>Xorg 6.8.2 builtin LTSP 4.1.1 - X growing constantly and memory is *not*
>>released even after you quit the application. The client eventually crash.
>>Xorg 6.8.2 shipped with RHEL 4 - same problem
>>XFree86 4.3, Suse 9.0 - same problem
>>XSun, Solaris 8, Sun Ultra 5 - unable to replicate the problem (was
>>working like a charm)
>>
>>So I think this must be a bug in the Xorg and Xfree86 servers as I was
>>not able to replicate this with Xsun X server.
>>I saw some discussion and there is a bug in Xorg 6.8.2. causing memory
>>leak when using Xcursor animated themes. Should be fixed in RC2.
>>I do not want that much - only a stable environment that does not crash
>>randomly.
>>
>>Ondrej
>>
>>Jim McQuillan wrote:
>>
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>>On Mon, 22 Aug 2005, Jason Maas wrote:
>>>
>>>
>>>
>>>
>>>
>>>>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 release the memory when it is done with
>>>>>it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Thanks for the explanation, it's very helpful for someone like me who's not
>>>>familiar with the nitty gritty details of X.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>So, for now, we have the NFS-Swap safety net, which is better than
>>>>>having the Xserver croak.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Definitely! So does NFS-Swap prevent X from getting nuked in all
>>>>situations?
>>>>Do you have any recommendations from your experience regarding RAM, swap, or
>>>>total combined memory size?
>>>>
>>>>Thanks so much for all of your hard work on LTSP, it's a fantastic project!
>>>>
>>>>Jason
>>>>
>>>>--
>>>>Jason Maas
>>>>DiscipleMakers Systems Dept -- www.dm.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>>_____________________________________________________________________
>>>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
>>>
>>>
>>>
>>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_____________________________________________________________________
>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: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_____________________________________________________________________
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