virtuoso-t memory consumption

Sun May 5 15:26:57 BST 2013

Chuck Burns posted on Sun, 05 May 2013 07:46:18 -0500 as excerpted:

> If you -aren't- using your RAM, then you are wasting it.  Free RAM means
> your system is not operating at peak performance.

Only to a point.  Beyond that, not so much.

If he's "only" running a 4-gig RAM system (I say "only", because I 
remember my first x86, with 4 /MB/ RAM... and I was rather late to the 
game, KB of ram..., but "only" definitely applies if a single app's using 
half of it!) and a single app's using half of it... he's well under that 
mark, and any memory freed from unnecessary bloated apps should be 
automatically put to use as cache, if nothing else.

But as someone who /has/ grown from a 4-meg memory system all those years 
ago, to a 16-gig system today, where much of it really /is/ free memory 
most of the time, not even cache filling it...

My application memory set is running ~750 MB ATM, about 3/4 gig.  I'm 
running ~380 MB buffer memory, and a bit over half a gig of cache.  Total 
usage including buffers and cache is ~1.7 gigs, so one could argue (as 
you apparently would) that I'm "wasting" 14 gigs. As it happens I 
rebooted only about 12 hours ago, and haven't done much to fill cache or 
use much app memory since then, but I my general working set is around a 
gig of app memory and several gigs of cache, still leaving perhaps half 
that 16 gigs entirely unused.

However, it isn't entirely wasted, because as I know from my 8-gig days, 
when I get the system busy doing something big, app memory will increase 
by several gigs, as will cache, until total use is over 8 gigs (including 
cache).  With 8 gigs physical that ends up topping off memory and 
discarding cache, thereby forcing the system to read data back in from 
disk the next time I want to look at something that had been cached but 
that was discarded from cache when memory got full.

With 16 gigs RAM (tho 12 would work about as well for my case, but 4 4-
gig sticks was technically better balanced), having all that normal-usage 
entirely free RAM means that when I do something big that ups both cache 
and app usage, I still don't end up over the top, which means full cache 
is retained and effectively, once I read something in from disk, it's 
cached until reboot (or for temporary mounts like my media and package 
repo mount, until I unmount...).  I no longer have to worry about going 
over the top.  Given that 16 gigs cost me well under $100 (IIRC it was 
about $80, $20/4-gig-stick, 4-sticks, or ~$5/gig), I'd say it was a 
worthwhile investment, even tho most of it is "wasted" most of the time.

But just running something to bloat out that memory so I'm not "wasting" 
it isn't going to help anyone, and the system certainly won't be running 
any more efficiently as a result, the argument you seem to be making.  
Sure, most of the time I've the memory to put to use, but that's the 
point, having the memory there to put to use when I need it, without 
having to kick out cached data that I'm going to need again reasonably 
soon, in ordered to use the memory for whatever else.

>From what I've seen, BTW, for my usage at least, a good generalized rule 
of thumb seems to be 1-2 GB RAM per core, somewhat more as the cores 
decrease toward 1, less as they increase toward the double-digits.  8 
gigs RAM was a very reasonable upper limit for my quad-core, 12 would be 
reasonable if stretching it a bit for my 6-core, but due to the 
packaging, 8 or 16 was most efficient so 16 it was.  But that gives me 
room to upgrade to an 8-core without worrying about RAM, if I decide to, 
later.  Still, 4 gig /is/ sort of wasted ATM, as I really don't often 
bust the 12 gig cap let alone the 16-gig.  But 8 gig would be a bit tight 
on a 6-core, tho not uncomfortably so, and I have 4 slots and wanted 
balanced RAM, so 4x4=16-gig it was.

> As far as "low fat kde" goes, sorry, but Linux is not the only player
> here.  But the OS that Gentoo took inspiration for it's portage system
> from, has also had custom compilation options for KDE, including not
> building Nepomuk, nor requiring the use of pulseaudio... FreeBSD and
> it's ports system.

It's true that I wasn't counting the non-linux *ixs.  Thanks for 
broadening the discussion horizon by bringing them in.

> Also, with ArchLinux, you have also -always- been able to get just parts
> of KDE as they were needed/wanted.  Plus, even though many KDE-based
> distros ship their systems with pretty much everything including the
> kitchen sink, does NOT mean you cannot simply remove the parts you do
> not want, including disabling Nepomuk completely.

Except... run-time disabling doesn't always mean you can get by without 
something installed.  If the library was linked in at build-time and it's 
not there at run-time, you get a segfault trying to run the app that 
linked it in.  (Yes there's certain caveats about lazy symbol loading and 
etc, but in general...)  In that case, it really /is/ a build-time 
decision -- you either build with support and force all users to have it 
available to link to even if they don't actually use that support to do 
anything, or you build without that support, and without the features it 
enabled.

Since some user somewhere is likely to find the support useful, most 
binary distros tend toward the bloated side, enabling far more than most 
of even the most demanding users actually use, because they don't all use 
the same features.  Other distros deliberately target a slimmed down 
profile, but that means some users do without features they'd use if they 
were included.  There's certainly a convenience of the binary distro, but 
that convenience just as certainly has a cost.  Some find that cost a 
good bargain for what they get, others don't.

However, I don't know to what extent nepomuk/virtuoso/et-al. fit the 
build-time-optional, run-time-required-if-linked-at-build-time, model.  I 
know the rather dramatic differences I saw here when I turned the build-
time options off as opposed to turning it off at runtime, but it's 
plausible that on binary distros at least some of that difference is 
available by uninstalling some of the components, as well.  I don't know 
to what extent they really are linked in and thus run-time-required even 
if turned off, in this particular case.

> Just because you enjoy "watching shit scroll by since 2005" doesn't mean
> it's the only way to get your system customized. :)

Who does that?  Certainly not /this/ gentoo user.  I run the update, then 
go do something else (like responding to these posts) while it does its 
thing.  After that it's not much different between binary and from-
source.  Major updates require the same config updates and period of 
adjusting to the new version, regardless of whether the user built it or 
the distro built it, and THAT's the part that takes the time, not the 
build process, which I think most gentooers eventually do in the 
background while they do something more interesting, once the newness of 
watching the build scroll by wears off, which doesn't take long...  
(There's also the rather separate question of rolling update vs periodic 
update, controlling whether those major updates come one or two at a time 
or all at once a time or two a year, but that really /is/ a different 
question, since both binary and source-based releases come in both 
flavors.)

But, just as I'm very glad there's gnome around for the devs who think 
there's "one true way" (aka the gnome-3 syndrome, previous aka the gnome2-
syndrome...) and the users who don't like all those confusing config 
options to worry about, because that keeps them out of the hair of the 
folks who recognize that people are different and that the dev's "one 
true way" might not fit a particular user's idea of /their/ true way, and 
thus exposing a config option allowing /both/ ways is a reasonable idea, 
so too am I very glad that there are binary distros for those who prefer 
them, who would rather someone else make those build-time decisions for 
them and find the loss of customization on the one hand and the extra 
bloat on the other a very reasonable cost indeed, to pay.  But neither of 
those cases is me! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.