Memory leak when (re)building cache

By deroby | March 27th, 2009 | 7:29 am

Hi there,

I’ve noticed the following behavior when running eBoostr 3.0 (Build 491).

When (re)building the cache, the EBstrSvc.exe eats up dramatically more memory with each iteration and does not release this anymore. After a while this results in eBoostr taking up most of my (virtual) memory, causing my computer to slow down to a crawl (“page thrashing”). I’m not 100% sure yet, but I suspect this also happens when the automatic (background) cache-update kicks in, thus causing long-running machines to run out of memory.

I work ‘around’ the issue by issuing the following commands now & then :
NET STOP “eboostr service”
NET START “eboostr service”

Some statistics on EBstrSvc.exe : (obtained from ProcessExplorer)

Situation / Private Bytes / Virtual size
after restart / 3,504k / 22,212k
build cache 1 / 152,192k / 188,624k
build cache 2 / 296,716k / 330,584k
build cache 3 / 440,416k / 472,554k
build cache 4 / 582,576k / 617,492k
build cache 5 / 726,104k / 759,452k
build cache 6 / 867,252k / 909,604k

etc…

This sequence is rather consistent when repeating the tests.

FYI : I have 1 USB stick, NTFS formatted, with a 4Gb cache on it (83% used).

If you’d need more info, feel free to ask.

23 Responses to “Memory leak when (re)building cache”

  1. Colonel ONeill
    Mar 29, 2009

    Wow. Never noticed it at all.

    Except mine doesn’t jump as seriously as yours.

    Starts at 3MB, then 6MB after the first rebuild.

    This is serious, and I hope those developers are taking note of this. It seems like the entire eBoostr team just disappeared. Oo


  2. deroby
    Mar 30, 2009

    Think I’ll have to experiment with some of the settings, colleague here has LITE version and he doesn’t have the issue at all.
    As for the dev team, the (well deserved) holiday is taking quite long now indeed =P


  3. deroby
    Mar 30, 2009

    Strange, did some testing with the config files found in All Users\application data and the effect of temporarily moving away a file is :
    * application.ini (4k) => no difference
    * exclude.ini (1k) => effect is smaller now :
    build cache 1 / 81,392k / 116,686k
    build cache 2 / 149,532k / 193,300k
    etc…
    * badlink.dat (99k) => no difference (required stopping CP)
    * filestat.dat (8924k) => effect is MUCH smaller now (+10,000K / +15,000k per iteration), but my cache device remains empty now (fill = 0%), which makes sense off course…

    Hope this helps… I’m minimizing my exclude list for the time-being, in combination with the restart every hour (AT is your friend) the overall effect is ‘survivable’.

    However, I now have a lot of stuff cached from my external disk, which I’d rather not have …


  4. medeni73
    Mar 30, 2009

    I can confirm the bug too. Whether you manually or automatically rebuild the cache, the memory footprint rises
    – normal state: 8,4 Mb (EBstrSvc.exe)
    – 1st build cache: 11,8 Mb
    – 2nd build cache: 13,1 Mb
    – 3rd build cache: 16,7 Mb

    stopping and starting again the eboostr service revert the memory footprint to 6 Mb


  5. chris
    Mar 30, 2009

    it seems that someone has forgotten to :

    free(allocatedRam);


  6. deroby
    Mar 30, 2009

    Still strange it’s that much bigger here…

    Anyway, for those who want to work around it (hope this gets through without too much reformatting issues) :

    Create a file “c:\restart_eboostr.bat” that contains these two lines :
    NET STOP “eboostr service”
    NET START “eboostr service”

    Then create a file “c:\set_eboostr_schedule.bat” with the following lines :
    at 0:00 /EVERY:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 “c:\restart_eboostr.bat”
    at 1:00 /EVERY:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 “c:\restart_eboostr.bat”
    at 2:00 /EVERY:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 “c:\restart_eboostr.bat”
    etc…

    You’ll need to run the set_eboostr_schedule once, after that, every hour the EBstrSvc.exe will be ‘reset’ and any lost memory is reclaimed. To get rid of this schedule again use the AT command (AT /DELETE will remove everything, so be careful!)


  7. Colonel ONeill
    Mar 30, 2009

    Maybe the amount of RAM eaten per cycle is proportional to the amount of space cached?

    I have a 64MB RAM cache. Don’t ask.

    With 4GB it seems it’s eating RAM up real fast, potentially negating the speed enhancements.

    Was this in older beta versions?


  8. nikomiudon
    Apr 02, 2009

    Vista32bitSP1 MEM4GB CacheDeviceSSD30GB(I secure 20GB, and 67% are used)
    The private byteses of EBstrSvc.exe exceed 1GB for a few days when I leave you unattended.


  9. nikomiudon
    Apr 05, 2009

    I can handle it as service in cronNT.
    http://www.vector.co.jp/soft/winnt/util/se232096.html

    automatic reboot service hourly
    crontab.ini
    0 * * * * net stop EBOOSTRSVC
    0 * * * * net start EBOOSTRSVC


  10. Willem
    Apr 12, 2009

    I would say : try for a time with FAT32 , may that helps


  11. Colonel ONeill
    Apr 12, 2009

    I found out that for some reason, EbStrSvc won’t show up in task manager (potentially 0 mem?), EB Control Panel says service not started, BUT

    The cache hits (second bar) continues to function, although that number degrades over time. Probably invalidated old contents.

    So, couldn’t EbStrSvc be activated for manual refreshes?


  12. deroby
    Apr 12, 2009

    I’ve had the ‘service not started’ message too on my dad’s pc.. (slowish machine), but after a while it changes to ‘Running’ … don’t think I’ve ever seen it “fail” after it had been running for some time…
    I guess the ‘overall cache hit ratio (top bar) and the ‘disk usage load’ (lower bar) will keep functioning as expected, but the middle bar won’t be doing anything while the service is not running…


  13. Willem
    Apr 12, 2009

    I think there is a database in EBstrSvc.exe that couples all ID numbers on CacheViewer with the place on the stick.
    I also think that when your stick is formatted as NTFS eBoostr can’t handle the addressing as well as with FAT32 , it’s totally different
    I think also that old addresses can’t be got rid of with NTFS ,so always more
    So , a lot of thinking , but not knowing the details there’s no other way.
    Excuse my english I’m Dutch


  14. deroby
    Apr 15, 2009

    Although I was pretty skeptical about this from the start, I gave the “use FAT32” advice a try.
    => removed the cache on my 16Gb NTFS USB stick
    => formatted the drive using FAT32
    => rebuild the cache (4Gb, 51% usage)

    The memory usage still jumps up exactly as it was with NTFS!

    Although I’ll admit not knowing the ‘deep innards’ of eBoostr; my guess is that the cache file is just a big binary file. The offsets are handled internally by eBoostr but are totally independent of the filesystem below. So wether you store your cache file on an NTFS, FAT32 or whatever partition, won’t make much of a difference.

    The only real workaround for now seems to be restarting the eBoostrSvc every now and then… (see my comment here : http://www.eboostr.com/closedbeta/feedback/memory_leak/comment-page-1/#comment-2042 )

    (that said, I’m now going back to NTFS…)


  15. fastest963
    May 16, 2009

    Any updates on this issue? Devs still on vacation?


  16. fastest963
    May 16, 2009

    Any updates on this? I also get the same results with Windows 7 and NTFS. Are the devs still on vacation?


  17. fastest963
    May 16, 2009

    Sorry for the double post, browser crashed and I didn’t see that it posted.


  18. Andrey Zarudnev
    May 18, 2009

    OK, thank you everybody for these reports and sorry for the delay. Unfortunately we are unable to reproduce such an issue on any of our test machines/OSes :(

    In a couple of days developers will prepare a special build with a detailed logging to help us spot the problem area.

    Thanks.


  19. Andrey Zarudnev
    May 19, 2009

    Finally we’ve managed to reproduce this leak on a Vista x64. We will try to release the fix ASAP.


  20. Andrey Zarudnev
    May 20, 2009

    Fixed version 3.0.1.498 was just uploaded and will be available through an autoupdate in several minutes. Thank you.


  21. medeni73
    May 22, 2009

    so far so good, ebstSvc.exe is around 4Mb. While rebuilding cache it goes higher but after its finished it goes again to standard value (ca 4 Mb)


  22. deroby
    May 22, 2009

    Installed the latest build and it seems to be fixed (for me that is =).

    FYI : Initial memory footprint is ca 6Mb, when rebuilding the cache it goes up to ca 16Mb, then falls back to ca 13Mb. Re-Rebuilding repeatedly makes it go up & down as expected and always ends up around 13Mb.
    Thx


  23. Andrey Zarudnev
    May 22, 2009

    Great! Thanks for an update.