Author Topic: b4: memory leak?  (Read 5416 times)

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
b4: memory leak?
« on: September 09, 2016, 08:11:18 PM »
After running b4 for a couple of days the "top" tool (linux) shows a RES of 2.4G with only a few small files open (though I opened/closed many files of various sizes during that period). Restarting brings memory use down to ~250MB for the same set of files. My current tag file cache size and max are both set to 64MB, and the buffer cache size to 2MB.

In case it's relevant: the files in my project are all added using wildcards and I do "Refresh" (Projects tool) rather often to pick up changes to the underlying directories. After the writing the paragraph above I hit refresh a few times and noticed that memory grows with each refresh (~10MB a pop).

Iker


Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #1 on: September 10, 2016, 01:57:49 AM »
We will look into this

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #2 on: September 11, 2016, 01:42:52 PM »
There doesn't seem to be a memory leak. It takes a bunch of invocations for the cache to get full. This gives the appearance of a memory leak.

Here's how I tested. I created a wildcard workspace with *.cpp and *.h for the Qt 4.8.7 source files. This is almost 22,000 files. I kept choosing the "Refresh" workspace context menu item in the projects tool window until memory stopped growing. I got the same results for Ubuntu and Windows. Eventually the cache gets full and memory usage doesn't grow any more.

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
Re: b4: memory leak?
« Reply #3 on: September 11, 2016, 03:40:49 PM »
How big can this particular cache grow?

In my first report the VS process grew to 2.4G after a couple of days. My current VS session has been going since yesterday and it's currently at 680MB with only small 4 files open.

Iker

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #4 on: September 11, 2016, 04:44:50 PM »
That's a lot larger than mine was but I didn't have other tag files.  No compiler file for gnu or Java.

I'll try adding those into some tests. I wanted to isolate what was being tested. I'll also see if I can get the memory usage higher be other means.

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #5 on: September 11, 2016, 05:14:41 PM »
2.4 gigabytes sounds ok. I got it to 1.7 gigbytes quickly by using auto-tag for the GNU and Java tag files, rebuilding this Qt workspace, and doing just a few refreshes.

Most of the memory is just for various tagging related caches. Large tag files and projects just eat tagging memory quickly. Project Tool window eats a bunch of memory to list 22k of files.

There's simply no way to keep this all high performance without tons of caches. Good thing we're not running on mobile devices.  ;D

Dennis

  • Senior Community Member
  • Posts: 3961
  • Hero Points: 517
Re: b4: memory leak?
« Reply #6 on: September 12, 2016, 05:27:34 PM »
I dialed back one of the tagging caches for the next build.  This should somewhat reduce the amount of memory usage.

Also, it is helpful to distinguish shared memory usage from other memory usage, because SlickEdit 2016 uses memory mapping for tag files, so if you have a lot of large tag files, it can appear that SlickEdit is using a lot more memory than it really is using.

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
Re: b4: memory leak?
« Reply #7 on: September 13, 2016, 02:09:49 PM »
At the end of this post is the script I'm using to measure vs_exe's "private" memory. At the moment I have only 6 small files open and the files that are part of my project are not changing. If I hit "Refresh" and immediately run the script I see the following progression:

Code: [Select]
$ python memusage.py 5504
private dirty: 333652 kB
shared dirty: 10520 kB
$ python memusage.py 5504
private dirty: 347664 kB
shared dirty: 10520 kB
$ python memusage.py 5504
private dirty: 364356 kB
shared dirty: 10648 kB
$ python memusage.py 5504
private dirty: 373896 kB
shared dirty: 10648 kB
$ python memusage.py 5504
private dirty: 385896 kB
shared dirty: 10648 kB
$ python memusage.py 5504
private dirty: 400912 kB
shared dirty: 10664 kB

Regards,
Iker

Code: [Select]
import platform
import sys

def get_mem_usage (pid):
    smaps = '/proc/%s/smaps' % pid
    raw = open(smaps, 'r').read()
    status = {}
    private_dirty = 0
    shared_dirty = 0
    for line in [i for i in raw.split('\n') if i ]:
        line = line.strip()
        if not line: continue
        k, v = (line.split(':')+["", ""])[0:2]
        if k.strip() == 'Private_Dirty':
            private_dirty += int(v.strip().split()[0])
        if k.strip() == 'Shared_Dirty':
            shared_dirty += int(v.strip().split()[0])
    return private_dirty, shared_dirty

if __name__ == "__main__":
    priv, shared = get_mem_usage(sys.argv[1])
    print "private dirty: %d kB" % priv
    print "shared dirty: %d kB" % shared

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
Re: b4: memory leak?
« Reply #8 on: September 13, 2016, 08:31:14 PM »
Behavior is similar with RC1. Immediately after starting (before doing anything else) private memory usage increases with every "Refresh".

Iker

Code: [Select]
$ python memusage.py 27258
private dirty: 118224 kB
shared dirty: 7580 kB
$ python memusage.py 27258
private dirty: 133228 kB
shared dirty: 7580 kB
$ python memusage.py 27258
private dirty: 149512 kB
shared dirty: 7596 kB
$ python memusage.py 27258
private dirty: 159780 kB
shared dirty: 7612 kB
$ python memusage.py 27258
private dirty: 174608 kB
shared dirty: 7612 kB
$ python memusage.py 27258
private dirty: 189092 kB
shared dirty: 7644 kB
$ python memusage.py 27258
private dirty: 203036 kB
shared dirty: 7644 kB

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #9 on: September 15, 2016, 07:17:44 PM »
We have found a memory leak in project refresh.

This will be fixed in RC 2

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
Re: b4: memory leak?
« Reply #10 on: September 22, 2016, 01:38:53 PM »
Reran the test on RC2 and memory use continues to grow.

The output labeled "1" below was generated immediately after starting RC2 and doing nothing but clicking on the "Refresh" button. Output "2" was generated after adding ~50 files to a directory that fell under one of my project's wildcard expressions and repeatedly hitting refresh. I then removed those same files and again hit "Refresh". Memory use grows in all three cases.

Iker

Code: [Select]
OUTPUT 1
> python memusage.py 24036
private dirty: 115624 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 115624 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 131956 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 137288 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 159560 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 165180 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 169928 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 177828 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 182036 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 185884 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 190152 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 197040 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 201740 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 202240 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 206356 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207180 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207276 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207356 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207556 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207624 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207672 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 207740 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 210048 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 210096 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 210288 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 210300 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 210492 kB
shared dirty: 8096 kB

Code: [Select]
OUTPUT 2:
> python memusage.py 24036
private dirty: 216720 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 223144 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 223144 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 223144 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 234316 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 246816 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 255780 kB
shared dirty: 8096 kB

Code: [Select]
> python memusage.py 24036
private dirty: 260008 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 267044 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 275048 kB
shared dirty: 8096 kB
> python memusage.py 24036
private dirty: 281220 kB
shared dirty: 8096 kB

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #11 on: September 22, 2016, 01:52:39 PM »
For better threading performance, SlickEdit has 16 memory caches instead of one to avoid memory allocation contention. It would be nice if this was configurable so users could choose between performance and memory usage.

Tagging is heavily threaded.

You probably need to run your test more than 20 times for the caches to be filled and memory reused.

IkerAriz

  • Senior Community Member
  • Posts: 159
  • Hero Points: 6
Re: b4: memory leak?
« Reply #12 on: September 22, 2016, 11:24:30 PM »
I tried disabling background tagging altogether and noticed that memory growth after each "Refresh" does go down, but not to zero. Is this expected behavior? (I'm using RC2)

Iker

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6867
  • Hero Points: 528
Re: b4: memory leak?
« Reply #13 on: September 23, 2016, 12:17:14 AM »
The Refresh code is using a thread. It's not run on the main thread so that the main thread doesn't have to wait for the operation to complete.

Each time a thread is run, it gets the next allocator (circular list). What I don't know is if there are any other threads being started at various times. That could make it take longer for the 16 caches to get filled since it's hard to know when all allocators are filled.