Ok Thanks, I'll take a look at that
I've got 6GB of system ram, haven't noticed any strange behaviour memory
wise, except sometimes I've seen a lot of kernel wait time when I'm doing
disk access maxing out one core at 100%.
I'm running 64bit where available and haven't seen high memory load on
anything or in general, but I'll have a play around and see if I can come up
with some scenarios that cause the problems.
I'm using the nvidia drivers have tried many versions from the stock with
mint-9 up until this one.
currently
ii nvidia-current 260.19.29-0ubuntu1~xup~lucid NVIDIA binary
Xorg driver, kernel module and VDPAU library
glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
system ram looks spaced out ok, Amarok is using the most at 128mb at the
moment, but I will have checked in the past to see if there's anything like
that causing the issues.
So what I'll do is
a: try to work out a quick way to reproduce the issue (and script it if
at-all possible)
b: then got through that process checking the resources as I go along.
c: then close a few things down to see if the system recovers as it has done
previously and again check resources etc...
d: do the same with some profiling in place at the same time, to see if
there's anything odd going on that obviously stands out.
e: Resend some emails, with updated details. All split up nicely
I think after I got through the bit about trying to get nepomuk and strigi
working (or findout what was going on) I realised that I'd bitten off more
than one email could chew, so tried to wrap it up a bit.
I think what I'll do is send one with the more diagnostics stuff with a few
issues I have. I could go through and just hammer it out and try everything
and possibly not get very far very quickly. So I thought it worth while
posting to the dev list to get a few hints and tips, and possible the reply
fixed in the next version or what have you... but it would still be nice to
find out where all the error logs and stuff are going and fix things up a
bit.
BTW: Are there any standard practise/ best practice with regard to trapping
errors like the one I had with with strigi lock and virtuoso? There's
obviously some trade off between my mum or girlfriend just clicking yes or
no or what-have you and having an automated work-around work (like I expect
deleting the transaxtion file would have worked, and cleaning out the lock
after checking to see if the process was running or not on login /logout),
but then there's a bit more of a technical way to do it. But still it would
be nice to be pointed in the right direction without having to poke around
or search the internet.
Just wondering, because I don't have any problem working
on implementing those kinds of solutions. (e.g. watching ~/.kde and /tmp and
seeing which things access which files and then I'v got a crude database
that lets me find out most of the possible files an application would
usually access for instance with very little effort to create it)
anyhow, that's a different question but I'd like to think a bit about it
before asking it properly, so if there's any policies or thought on that try
of solution to make it easier for 'me' to track things down and easier on my
email client because my mum won't be sending me emails when something needs
attention on the computer because there's an automated workaround/patch in
place.
Thanks,
Oliver Stieber.
On Sat, Jan 8, 2011 at 12:16 AM, Thomas Lübking
<thomas.luebk...@gmail.com>wrote:
> Am Friday 07 January 2011 schrieb oliverthered:
> > I'm getting an issue what appears to be GPU memory issues, specifically
> the
> > memory seems to be getting eaten up quite quickly even though I've got
> > loads of system ram and not a huge number of application windows or apps
> > running. I belive my graphics card has 512MB or ram or maybe 1GB but it's
> > a GeForce 7900 GS.
> "nvidia" or "nouveau"?
>
> > I've changed over to none oxygen version of everything (as that was
> pointed
> > to as the culprit for some leakyness), but closing down windows seems to
> > free up the ram and I can run things like projectM full screen again and
> > with no performance issues.
> Can you actually confirm that the RAM hunger is distributed evenly among
> your
> running applications ("top") and not everything is just sucked by only one
> (X11?) process?
>
> Usually graphical stuff (including and good god esp. opengl) ends up in
> your
> VRAM (ie. on the GPU), you can query the used X11 resources by "xrestop"
>
> in doubt: ask your distro whether they run anything (everything...) by
> "--graphicssystem raster" and then tell them to stop doing this ;-)
>
> > I would have expected that opengl should put stuff into system memory as
> > it's ment to do it's own memory mangement, at least for some stff etc...
> yes, as last resort - but your GPU can carry some windows before mapping to
> sysram.
> please notice that ARGB enabled windows will take 33% more memory than
> "ordinary" ones. konsole and most plasma-desktop windows use ARGB and we
> recently figured that apparently gdk driven GL clients (like at least eg.
> cairo-dock) will make all Qt clients (or rather everything?) use ARGB
> drawables
>
> the nvidia driver has however it's very own pitfall.
> call "nvidia-settgins -a PixmapCache=0; nvidia-settgins -a PixmapCache=1"
> from
> time to time (every 30 minutes and right after your desktop is loaded) to
> improve performance...
>
> sidenote:
> consider to split up the mail, strip it a bit ... more... and resend it
> =P
>
> Cheers,
> Thomas
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
