[kde-solaris] ... people are running KDE3 on systems with as
little as 64MB for daily use.
Eva Brucherseifer
eva at kde.org
Thu Jan 29 14:07:43 CET 2004
Am Mittwoch, 28. Januar 2004 11:41 schrieb Rolf Sponsel:
> Please bear with me ;-) this is *not* a flame.
> I'm just trying to understand this better.
>
>
> Obviously there is something that I
> haven't understood yet about Solaris.
>
> From my understanding, for Solaris 2 (SPARC),
> the *available memory* is RAM + SWAP (which
> can be either on a separate partition, or
> a swap file on any ordinary partition).
>
> Additionally, the '/tmp' file system (by
> default) is allocated from the space of
> available memory.
This indeed might be the reason for the confusion. KDE stores temporary data
to /tmp/kde-$user including temprary downloads. This directory is created for
each user and not cleared at logout. At the end of my email is my /tmp/
kde-eva on a linux box. You see there e.g. a partly downloaded iso-image -
this of course can eat lots of your available swap space...
So I see three methods to do something against it:
* clear these directories at logout (by placing a script into $KDEDIRS/bin/
shutdown/), you can check the path with this command:
/opt/kde3/bin/kde-config --path exe
* link /tmp to another location (as already suggested)
* place kde's temp files to another directory:
These directories are set by the following part in KDE's startup script
(startkde):
---------- from startkde -----------------------
# Link "tmp" resource to directory in /tmp
# Creates a directory /tmp/kde-$USER and links $KDEHOME/tmp-$HOSTNAME to it.
lnusertemp tmp >/dev/null
# Link "socket" resource to directory in /tmp
# Creates a directory /tmp/ksocket-$USER and links $KDEHOME/socket-$HOSTNAME
to it.
lnusertemp socket >/dev/null
----------------------------------------------------
You can change the location by setting the temporary variable $KDETMP to
another location before this call. Default is "/tmp".
Greetings,
eva
------------------ content of temporary kde dir ---------------------
drwx------ 4 eva users 8192 2004-01-29 13:43 .
drwxrwxrwt 23 root root 4096 2004-01-29 13:45 ..
drwx------ 2 eva users 4096 2004-01-29 13:43 Desktop-0
drwx------ 2 eva users 4096 2003-10-17 23:26 Desktop-%1
-rw------- 1 eva users 0 2003-11-23 13:00 kalarmddWjb5b.tmp
-rw------- 1 eva users 405 2003-10-17 23:40
konqueror-crash-bawQIa.logdrwx------ 4 eva users 8192
2004-01-29 13:43 .
drwxrwxrwt 23 root root 4096 2004-01-29 13:45 ..
drwx------ 2 eva users 4096 2004-01-29 13:43 Desktop-0
drwx------ 2 eva users 4096 2003-10-17 23:26 Desktop-%1
-rw------- 1 eva users 0 2003-11-23 13:00 kalarmddWjb5b.tmp
-rw------- 1 eva users 405 2003-10-17 23:40
konqueror-crash-bawQIa.log
-rw------- 1 eva users 2764 2004-01-11 14:11
konqueror-crash-BQLeHa.log
-rw------- 1 eva users 9339 2003-12-31 14:23
konqueror-crash-HYhwnb.log
-rw------- 1 eva users 2653 2003-10-17 23:32
konqueror-crash-J2TBOa.log
-rw------- 1 eva users 10350 2003-12-13 14:01
konqueror-crash-MtOgfa.log
-rw------- 1 eva users 168 2004-01-11 14:02
konqueror-crash-mx91tc.log
-rw------- 1 eva users 51 2004-01-29 13:44
konqueror-crash-Z4zvua.log
-rw------- 1 eva users 5086080 2004-01-05 03:16
konquerorFqoTUb.2.iso.part
-rw-r--r-- 1 eva users 29184 2003-11-16 18:38
konquerorl8sCWb.tmp
-rw-r--r-- 1 eva users 361728 2003-11-16 18:39
konquerormi9q9b.tmp
-rw-r--r-- 1 eva users 37051 2003-11-16 18:39
konquerortsw9Ja.tmp
-rw------- 1 eva users 38880 2004-01-27 19:48
konqueroruRsisb.7.0-1su82.i386.rpm.part
-rw------- 1 eva users 5895680 2004-01-05 03:15
konquerorWqJiFb.2.iso.part
-rw------- 1 eva users 3668 2004-01-10 16:50 ksirc3Gizlb.tmp
-rw-r--r-- 1 eva users 1165806 2004-01-29 13:43 ksycoca
-rw-r--r-- 1 eva users 782 2004-01-29 13:43 ksycocastamp
-rw------- 1 eva users 1256064 2004-01-10 15:38
kwrite1qPu3b.5.iso.part
-rw------- 1 eva users 0 2004-01-11 18:07 kwriteAsXq6a.6.iso
-rw------- 1 eva users 272512 2004-01-11 18:07
kwriteAsXq6a.6.iso.part
-rw------- 1 eva users 2764 2004-01-11 14:11
konqueror-crash-BQLeHa.log
-rw------- 1 eva users 9339 2003-12-31 14:23
konqueror-crash-HYhwnb.log
-rw------- 1 eva users 2653 2003-10-17 23:32
konqueror-crash-J2TBOa.log
-rw------- 1 eva users 10350 2003-12-13 14:01
konqueror-crash-MtOgfa.log
-rw------- 1 eva users 168 2004-01-11 14:02
konqueror-crash-mx91tc.log
-rw------- 1 eva users 51 2004-01-29 13:44
konqueror-crash-Z4zvua.log
-rw------- 1 eva users 5086080 2004-01-05 03:16
konquerorFqoTUb.2.iso.part
-rw-r--r-- 1 eva users 29184 2003-11-16 18:38
konquerorl8sCWb.tmp
-rw-r--r-- 1 eva users 361728 2003-11-16 18:39
konquerormi9q9b.tmp
-rw-r--r-- 1 eva users 37051 2003-11-16 18:39
konquerortsw9Ja.tmp
-rw------- 1 eva users 38880 2004-01-27 19:48
konqueroruRsisb.7.0-1su82.i386.rpm.part
-rw------- 1 eva users 5895680 2004-01-05 03:15
konquerorWqJiFb.2.iso.part
-rw------- 1 eva users 3668 2004-01-10 16:50 ksirc3Gizlb.tmp
-rw-r--r-- 1 eva users 1165806 2004-01-29 13:43 ksycoca
-rw-r--r-- 1 eva users 782 2004-01-29 13:43 ksycocastamp
-rw------- 1 eva users 1256064 2004-01-10 15:38
kwrite1qPu3b.5.iso.part
-rw------- 1 eva users 0 2004-01-11 18:07 kwriteAsXq6a.6.iso
-rw------- 1 eva users 272512 2004-01-11 18:07
kwriteAsXq6a.6.iso.part
------------------------
>
> Now, if one has a set of applications that
> run fine on, let's say 128MB RAM (alt .5GB)
> and 384MB SWAP (alt 1.5GB); then I don't
> understand why that *same* set of applications
> with the configuration .5GB (alt 2GB) and
> 0MB SWAP (alt 0GB) should *not* run fine.
>
>
> Best Regards / Rolf
>
>
> Ps. I could accept the "magic" fact that one
> needs a swap of about 3 times RAM, but I
> do not yet understan why. I'm sure it's
> explained somewhere, but so far I haven't
> managed to find that information/document.
>
> Stefan Teleman wrote:
> > The problems you are having are not related to RAM. They are directly
> > caused by the size of your swap partition, which is too small. If you
> > increase swap to at least 3 times core RAM, you will no longer have
> > these problems. I personally know of at least one person happily
> > running the same 3.1.4 binaries on an Ultra 5 with 256MB RAM, and
> > with a correctly sized swap (which in this particular case, is more
> > than 3 times RAM).
> >
> > Comparing identical software's memory footprint between 2 different
> > OS's running on different hardware architectures built with different
> > compilers is not relevant. Binaries at identical software release
> > numbers, from identical source code, will have different sizes on
> > different operating systems with different compilers.
> >
> > I cannot confirm any of these miniature KDE sizes running on Linux,
> > and i have been running KDE on Linux (RedHat) since KDE 2.2.
> > Currently, i am running 3.1.4, with the binary build downloaded from
> > KDE, on RedHat 9, on a 1.2GHz P4 with 512MB ThinkPad. It is
> > configured with 1.5GB swap. With only KMail, 4 xterms and one Konsole
> > running, i see a memory footprint of 420MB in use, and 170MB swap in
> > use, as reported by KSysguard (the swap could very well be some other
> > system stuff running in the background).
> >
> > These sizes are consistent with what i see on the Solaris build (it's
> > actually less on Solaris, for the same exact apps), and with what i
> > have seen with KDE 3.0.* on Linux.
> >
> > I also do not remember KDE 2.2 using less than 350MB RAM on Linux.
> >
> > Even with this resource footprint, this laptop performs very well its
> > additional duties of NFS and NIS server for my 2 Sun boxes at home,
> > and i am exporting an external USB drive with two 40GB partitions.
> > And i can also build additional KDE software from source, with gcc,
> > on this laptop, while it's doing its job.
> >
> > --Stefan
> >
> > ----
> >
> > On Tuesday 27 January 2004 12:16, michael.szengel at philips.com wrote:
> >>Since I am the guy who caused this discussion I would like to share
> >>my personal (over 10 years) experience with memory usage of Sun
> >>systems and finally ask for a reason.
> >>I never experienced memory shortages on our Sun systems running
> >>only a desktop since the days of SPARCstation 1 with 16 MB RAM and
> >>about 45 MB swap (not counting the cases when sombody was trying to
> >>start a whole chip simulation on his desktop mashine ;-).
> >>For 4 years, my colleagues work on Ultra10 / Sun BLade 100 with 512
> >>MB RAM and 1 GB swap ... and never problems with memory. Some of
> >>them open up to 10 desktops with dozens of terminals, xemacs and
> >>other stuff. They criticized the Xserver because they can not open
> >>more than about 80 windows at a time due to a resource limitation
> >>inside of X but they never run into memory problems under KDE2 (gcc
> >>version).
> >>Now I installed KDE3 from Stefan on my mashine to try it out and
> >>only the KDE3 desktop with some terminals and other desktop tools
> >>(not talking about MATLAB or a VHDL simulator, which is quit common
> >>to use for smaller tasks on our desktops here as well) let crash my
> >>Sun due to a shortage of memory !!!!
> >>
> >>I do not have a explanation for the tremendious increase in RAM
> >>usage. And this has been the main reason for me not to start with
> >>a rollout of the otherwise stable KDE3 release from Stefan because
> >>I will have to repartition / reinstall all my Sun desktops.
> >>
> >>Any root cause explanation of this effect is very welcome and I
> >>would be very happy if the myth about KDE3 on 64MB RAM becomes a
> >>reality ;-)
> >>
> >>Just my experience, not a flame.
> >>
> >>Michael
More information about the kde-solaris
mailing list