Memory leaks in Ubuntu?

[Stephen]

i know all nvidia cards have a "turbo Cache" option to swipe some
system memory for graphics rendering it may be that the driver is
grabbing this and not releaseing it back.. this may be the killer.

how to resolve. i am not sure.

On Wed, Aug 5, 2009 at 8:46 PM, Michael Butash<michael at butash.net> wrote:
> True enough it is tied to caching, but the fact it's marked as inactive
> when I can definitely attribute application termination from lack of
> memory is what I note as a problem.  The system does not give this back
> in the way of virtual or physical memory.  The system does however
> behave well enough as long as physical memory is present to give, but
> watching a graph of the physical memory is *like* watching a memory
> leak, whether it properly is or isn't, and end of the road is definitely
> noticeable with performance on said system.
>
> Here's what a normal vmstat looks like currently, notice the caching:
>
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
> id wa
>  0  0   4096 224988  69472 5676224    0    0     2    31   12   41  7  6
> 86  1
>
> Here's what vmstat -a looks like currently with "inact" having most:
>
> mb at thrawn:~$ vmstat -a
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>  r  b   swpd   free  inact active   si   so    bi    bo   in   cs us sy
> id wa
>  2  0   4096 223196 5737708 1900724    0    0     2    31   12   41  7
> 6 86  1
>
> Physical memory has nothing with free -m:
>
>             total       used       free     shared    buffers
> cached
> Mem:          7888       7673        214          0         68
> 5543
> -/+ buffers/cache:       2062       5826
> Swap:         1023          4       1019
>
> When it loses all physical memory, the system slows waay down, java apps
> get weird (jbidwatcher is the java cancer for me), anything rendering
> video won't scale, my gl screensaver bogs waaay down.  Totem, vlc, or
> other will simply just crash if run long enough in this state, but I
> haven't caught the segfault or anything.
>
> I've used just about any build within the past 4 years or so of the NV
> proprietary drivers, and nothing resolves it, though many have said
> there are issues with 64bit.  I can't attribute anything to actually
> using the memory, and typically where I've seen leaks like this I can
> always find something even in excess processes running away or ipc
> threading even.
>
> I've lived with it so long it's just just *there*, but I'd kill to fix
> whatever the heck it is.  No amount of research has ever resulted in a
> fix for me.
>
> Thanks for the input!
>
> -mb
>
>
> On Wed, 2009-08-05 at 20:19 -0700, Joseph Sinclair wrote:
>> I have had major problems with the NVidia proprietary drivers, particularly with Ubuntu 9.04.  It seems like NVidia introduced a ton of REALLY bad bugs when they had to almost rewrite the drivers for the changes in the new XOrg server.
>> I haven't seen the memory behavior you describe, but have you checked to be certain this isn't buffers and/or cache memory?  I know all of my machines running any desktop distro tend to slowly accumulate cache until me
>> mory is "full", but none of them have performance issues, since the kernel just reclaims cache LRU when it needs the RAM back.  I also see fairly large amounts of "inactive" memory, but I never seem to have problems with the system reclaiming that as needed.
>>
>>
>> Michael Butash wrote:
>> > Has anyone else seen or experienced persistent memory leaks with ubuntu
>> > 32bit or 64?  I've literally had issues with it that may or may not be
>> > particularly ubuntu issues back to 7.04 that I first noticed.  The only
>> > thing really in common system-wise is the hardware, and I somewhat
>> > suspect it's Nvidia driver related, but nothing really indicates any
>> > particular app.  My primary desktop I use heavily just about anything,
>> > but I have another system that's sole purpose is to play movies and
>> > music on my TV I do almost nothing with that experiences the same
>> > issues, NVidia card as well.  With compiz or without this happens.  Only
>> > thing I haven't tried is running the NV drivers, but I rely on the
>> > acceleration far too much on both systems.
>> >
>> > What I have noticed is there are no direct applications hogging memory
>> > via top, rather it seems virtual memory ends up simply taking over all
>> > physical memory and keeping it as "inactive" via "vmstat -a".  Signs of
>> > this include firefox flipping out, rendering/scaling video larger than
>> > default, and just anything else that requires excessive memory use
>> > having issues.  I graph my physical memory usage via snmp, and I can
>> > pretty accurately gauge how long I have until I need to do a hard reboot
>> > to reclaim the "inactive" memory.  It mostly works even memory starved
>> > in this condition, just limits my usage, and even restarting x doesn't
>> > help.  Interestingly enough, neither system ever swaps at all...
>> >
>> > Has anyone successfully ever dealt with an issue like this killing
>> > virtual memory?  I really can't imagine I'm the only one...  I've hunted
>> > far and wide of the great interweb for a way to release the "inactive"
>> > memory, as I'd even just go so far as to purge it once a day via cron if
>> > I had to, but I can find nothing of forcefully clearing inactive/dirty
>> > virtual memory space.  I've seen others complain of the same behavior,
>> > but have only seen the same rhetoric that "trust linux virtual memory
>> > behavior, that's what it's supposed to do".  Act like a stupid windoze
>> > me install and reboot daily?  I think not...
>> >
>> > -mb
>> >
>> > ---------------------------------------------------
>> > PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> > To subscribe, unsubscribe, or to change your mail settings:
>> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>> >
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>



-- 
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.

Stephen