[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: About memory allocation failures....
From:       Rik Hemsley <rik () kde ! org>
Date:       2002-02-08 16:17:37
[Download RAW message or body]

#if Kuba Ober
> I'm just saying that a top-of-the notch mid-sized machine: very good
> motherboard, 2xpiii, 1gig ecc ram, 2gig swap, very-fast scsi-based
> drives (100mbyte/s xfer), up-to-date freebsd os, is not able to cope
> with more than 15-20 users trying to play with recent kde desktop at
> the same time.

When you say 'not able to cope', what exactly do you mean ? Is it just
that you are low on memory, or are you getting too much CPU or I/O use ?

> Another thing is that kde apps don't behave nicely when process rss
> limit is 16mb, at least not on that freebsd system. Effect is that
> applications "vanish" when you're using them. Now, for a multi-user
> system with 1gig of ram, with 50 users typically logged in (text
> sessions) during peak hours, there's no point in having per-user rss
> limit higher than 16mb - it could have as well been nonexistent.

Setting a per-user RSS limit of 16Mb is not going to work if you're
letting people use apps like konqueror, because one large web page will
instantly take you over that. There's a big difference between a modern
web browser handling all kinds of stuff like XML, DOM, etc., and an IRC
client.

One option for you, rather than having people's apps simply disappear,
is to patch my naughtyapplet (see kdebase/kicker/applets/naughty) to
make it work on FreeBSD and to watch memory usage too. This would allow
you to inform the user when one of their apps is approaching your
defined limit, and to ask them to e.g. shut it down within one minute,
plus talk to the admin to see if you can find a way to do what they want
without eating so much memory.

> Most of it can be attributed to current gcc in cooperation with Qt, I
> believe, since C++ code and data sharing doesn't work miracles yet,
> I'm afraid. I presume that a simple thing as mmap-ing all resource
> files (icons, disk-based html help files, etc.) would help things a
> lot, but that's not all. Or maybe it's already done that way???

We hardly use mmap, only for KConfig AFAIK. Perhaps we should.

> A lot of memory in kde apps running on multiuser servers is wasted to
> store same things over and over....  I did a full memory dump once on
> big system running many kde user sessions, and whooping 7% of pages
> (and page-sized memory chunks, as all offsets were tested) had exact
> duplicates, and about 20% had duplicates with small differences only -
> loader fixups :-(( These are resident, live, physical in-ram pages,
> I'm not talking about swap. All of these pages were owned by kde
> processes (applications).

Hmm, I thought the OS would have merged the duplicate pages, but of
course it can't with ones that have small differences. Any ideas how
that could be fixed ? I'd be interested to hear if it's just a gcc bug,
or if there's some complex problem behind it, and whether it's FreeBSD
specific or if it happens on Linux too.

Rik

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]