Memory leak when (re)building cache
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.
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
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
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 …
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
Mar 30, 2009
it seems that someone has forgotten to :
free(allocatedRam);
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!)
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?
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.
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
Apr 12, 2009
I would say : try for a time with FAT32 , may that helps
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?
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…
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
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…)
May 16, 2009
Any updates on this issue? Devs still on vacation?
May 16, 2009
Any updates on this? I also get the same results with Windows 7 and NTFS. Are the devs still on vacation?
May 16, 2009
Sorry for the double post, browser crashed and I didn’t see that it posted.
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.
May 19, 2009
Finally we’ve managed to reproduce this leak on a Vista x64. We will try to release the fix ASAP.
May 20, 2009
Fixed version 3.0.1.498 was just uploaded and will be available through an autoupdate in several minutes. Thank you.
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)
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
May 22, 2009
Great! Thanks for an update.