[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [K12OSN] Client Ram

All I asked was if I could get away with less RAM ;-) and look what I started. Well, I'm probably going to end up with 128 in all of them anyways. It occurred to me that if one of the XP boxes need a stick of 64 in it then it probably needed lot more than just 64. It seems like they had to make a fair trade in the use of resources with the xserver. I'd rather have to increase the ram in a client by 32mb then to increase network bandwith and push it back to the server. Thanks for the input.


-----Original Message-----
From: k12osn-bounces redhat com on behalf of Jim McQuillan
Sent: Fri 5/25/2007 7:06 AM
To: Support list for open source software in schools.
Subject: Re: [K12OSN] Client Ram

Daniel Bodanske wrote:
> So Firefox stores pixmaps uncompressed in the X server cache.
> Unbelievable. Is it Firefox or Gecko? Does Seamonkey suffer the same
> limitation. Could you move to Epiphany? Wow.

This is not unusual.  everybody seems to be implying that firefox is 
being evil by doing this.

The Xserver caches pixmaps and fonts.  No big deal.  It's part of the 
design of the X Window System.  The problem is, with tabs, the browser 
can actually be viewing more than one page at a time, which means there 
can be alot more pixmaps sent from the browser to the Xserver.  The 
Xserver just happily caches them.

A flaw in this design is the fact that when the thin client gets low on 
memory, the Xserver has no mechanism to deal with it.  It can't throw 
away pixmaps from the cache, because it has no way of telling the client 
application that it no longer has the image cached, so there's no way 
for firefox to re-send the pixmap when the user comes back to that page.

So, sadly, the Xserver runs out of memory, and bad things happen.

I've brought this up to the X.org developers and everybody agrees that 
it's a big problem, but unfortunately, there's not an easy fix.

It's not just firefox that is involved here. Any graphical application 
will send images and fonts to the Xserver, and expect those things to 
still be in the Xserver later on.  I suppose Firefox could be modified 
to never expect those things to be cached, which means it would have to 
send the images and fonts each time you switch from one tab to another, 
or scroll the page up and down.  Imagine the screams you'd be hearing as 
the performance goes down the tubes, and the network traffic goes 
through the roof.

We tried fixing this a few years ago in LTSP by placing a limit on how 
much ram the Xserver could allocate.  This managed to keep the Xserver 
from crashing, but then the client application would crash because it 
didn't expect the Xserver to fail to allocate the memory for it.  If the 
client is the browser, the browser would crash, which is easily 
recoverable.  But, what if the client application is something more 
important, like the window manager?

It's a tough problem, and I wish I had the magic fix for it.

Jim McQuillan
jam Ltsp org

> I began to get scared a few years ago when so many new desktop
> applications started to get written for Linux. So many of them
> wouldn't work over the network. I got worried that LTSP might become
> non-viable some day when all the standard apps needed local resources.
> Once Freedesktop.org was started and picked up momentum with Jim as
> one of the founding members, I calmed down, but I guess I shouldn't
> have. Firefox seems to follow it's own rules all the time, anyway.
> Dan
> On 5/25/07, Dan Young <dyoung mesd k12 or us> wrote:
>> On 5/24/07, Rob Owens <rowens ptd net> wrote:
>> > So maybe the question should be:  Is there a browser that it better
>> > suited to LTSP than Firfox is?
>> Well, part of it comes down to tuning. Eric put together a Firefox
>> extension that sets several options to more friendly levels. In
>> particular:
>> browser.cache.memory.capacity
>> and
>> browser.sessionhistory.max_total_viewers
>> The defaults are variable depending on the total memory of the
>> computer. Of course, in an LTSP environment, it's all shared, so a 4G
>> host can't expect to have all that for one browser instance.
>> As I understand it, the defaults have been dialed back somewhat for
>> Firefox 2. Eric's Firefox extension dials back these values too.
>> http://www.redhat.com/archives/k12osn/2006-May/msg00372.html
>> -- 
>> Dan Young <dyoung mesd k12 or us>
>> Multnomah ESD - Technology Services
>> 503-257-1562
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN redhat com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see <http://www.k12os.org>
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>

K12OSN mailing list
K12OSN redhat com
For more info see <http://www.k12os.org>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]