When you create an instance of the cachefactory and then don’t use it anymore the memory that was used during the creation of the object is not released. This will have a substantial effect on all web apps or scenarios where a cachfactory might be created multiple times. The symptoms of this will be unusually high memory use one the process and in IIS this will most likely result in your app having to recycle more often since it with overrun its allocated memory more quickly.
The following code will show an increase of about 500MB yes I mean MegaBytes of memory usage!
To duplicate put the following code into your app:
Dim CacheFactory1 As CacheFactory = New CacheFactory()
For i As Int32 = 1 To 1 * (10 ^ 4)
CacheFactory1 = New CacheFactory()
CacheFactory1 = Nothing
Next
There are only two workarounds for this.
Velocity team fixes the bug (and I’m sure they will)
You need to use the same cachefactory object on a static method in your app and reference it every time you want to use the cache. (this works but isn’t optimal in my opinion.)
I also have a cachingscope that can be used to wrap your caching methods and will post this on codeplex soon. You can wrap it around your caching methods just like a transaction scope and it will manage the locking and connection for you.
So where is the question? You should file the bug, and not post this here, as the Velocity team is more than likely monitoring Microsoft Connect for bugs.
I've build a scope provider for resolving this issue. You can get the code here.
http://www.codeplex.com/CacheScope
Related
I'm running Node.js / Express server on a container with pretty strict memory constraints.
One of the endpoints I'd like to expose is a "batch" endpoint where a client can request a list of data objects in bulk from my data store. The individual objects vary in size, so it's difficult to set a hard limit on how many objects can be requested at one time. In most cases a client could request a large amount of objects without any issues, but it certain edge cases even requests for a small amount of objects will trigger an OOM error.
I'm familiar with Node's process.memoryUsage() & process.memoryUsage.rss(), but I'm worried about the performance implications of constantly checking heap (or service) memory usage while serving an individual batch request.
In the longer term, I might consider using memory monitoring to bake in some automatic pagination for the endpoint. In the short term, however, I'd just like to be able to return an informative error to the client in the event that they are requesting too many data objects at a given time (rather than have the entire application crash with an OOM error).
Are there any more effective methods or tools I could be using to solve the problem instead?
you have couple of options.
Options 1.
what is biggest object you have in store. I would say that you allow some {max object count} on api and set container memory to biggestObject x {max allowed objects size}. You can even have some pagination concept added if required where page size = {max object count}
Option 2.
Also using process.memoryUsage() should be fine too. I don't believe it is a not a costly call unless you have read this somewhere. Before each object pull check current memory and go ahead only if safe amount of memory is available.The response in this case can contain only pulled data and lets client to pull remaining ids in next call. Implementable via some paging logic too.
options 3.
explore streams. This I will not be able to add much info for now.
I am trying to use the Observatory tab in dartium dev tools, to find a memory leak in my framework. I have made a test program here which should be viewable in js or dart. My goal is to find out where references are holding on to Massive objects, which are just wrappers around a List<double> with a million doubles in it. If I click New Client I get a new client view on the right, if I generate a bunch of Massive objects and refresh the observatory tools I see that double now takes up most of the app memory usage. If I then delete the Massive objects and wait 5 seconds for the frameworks remote garbage collection to run, then refresh the observatory tab, the doubles still occupy the same amount of memory even though they should have been GC'd (I click the GC button on the observatoy tab to, I assume, force the GC to run.) If I keep creating and deleting Massive objects in the app eventually the page crashes, typically after around 28 Massive objects have been created. My problem is finding out how to use the tools to find out where the Massive objects are still having references hold on to them. Is it possible to get find references to objects in the dev tools?
UPDATE:
I have fixed the memory leak in the test app I link too and describe above, therefore following the instructions above will not result in recreating the memory leak.
I'm currently investigating a memory leak myself. What's missing in the observatory is a way the chain from the root to the leaking object. I'm not sure if there is already an issue open for it, though. Feel free to open a new one.
I am using the NodeJS VM Module to run untrusted code safely. I have noticed a huge memory leak that takes about 10M of memory on each execution and does not release it. Eventually, my node process ends up using 500M+ of memory. After some digging, I traced the problem to the constant creation of VMs. To test my theory, I commented out the code that creates the VMs. Sure enough, the memory usage dropped dramatically. I then uncommented the code again and placed global.gc() calls strategically around the problem areas and ran node with the--expose-gc flag. This reduced my memory usage dramatically and retained the functionality.
Is there a better way of cleaning up VMs after I am done using it?
My next approach is the cache the vm containing the given unsafe code and reusing it if it I see the unsafe code again (Background:I am letting users write their own parsing function for blocks of text, thus, the unsafe code be executed frequently or executed once and never seen again).
Some reference code.
async.each(items,function(i,cb){
// Initialize context...
var context = vm.createContext(init);
// Execute untrusted code
var captured = vm.runInContext(parse, context);
// This dramatically improves the usage, but isn't
// part of the standard API
// global.gc();
// Return Result via a callback
cb(null,captured);
});
When I see this right this was fixed in v5.9.0, see this PR. It appears that in those cases both node core maintainer nor programmers can do much - that we pretty much have to wait for a upstream fix in v8.
So no, you can't do anything more about it. Catching this bug was good though!
I was trying to find some resources for best performance and scaling with message passing. I heard that message passing by value instead of reference can be better scalability as it works well with NUMA style setups and reduced contention for a given memory address.
I would assume value based message passing only works with "smaller" messages. What would "smaller" be defined as? At what point would references be better? Would one do stream processing this way?
I'm looking for some helpful tips or resources for these kinds of questions.
Thanks :-)
P.S. I work in C#, but I don't think that matters so much for these kind of design questions.
Some factors to add to the excellent advice of Jeremy:
1) Passing by value only works efficiently for small messages. If the data has a [cache-line-size] unused area at the start to avoid false sharing, you are already approaching the size where passing by reference is more efficient.
2) Wider queues mean more space taken up by the queues, impacting memory use.
3) Copying data into/outof wide queue structures takes time. Apart from the actual CPU use while moving data, the queue remains locked during the copying. This increases contention on the queue and leading to an overall performance hit that is queue width dependent. If there is any deadlock-potential in your code, keeping locks for extended periods will not help matters.
4) Passing by value tends to lead to code that is specific to the data size, ie. is fixed at compile-time. Apart from a nasty infestation of templates, this makes it very difficult to tune buffer-sizes etc. at run-time.
5) If the messages are passed by reference and malloced/freed/newed/disposed/GC'd, this can lead to excessive contention on the memory-manager and frequent, wasteful GC. I usually use fixed pools of messages, allocated at startup, specifically to avoid this.
6) Handling byte-streams can be awkward when passing by reference. If a byte-stream is characterized by frequent delivery of single bytes, pass-by-reference is only sensible if the bytes are chunked-up. This can lead to the need for timeouts to ensure that partially-filled messages are dispatched to the next thread in a timely manner. This introduces complication and latency.
7) Pass-by-reference designs are inherently more likely to leak. This can lead to extended test times and overdosing on valgrind - a particularly painful addiction, (another reason I use fixed-size message object pools).
8) Complex messages, eg. those that contain references to other objects, can cause horrendous problems with ownership and lifetime-management if passed by value. Example - a server socket object has a reference to a buffer-list object that contains an array of buffer-instances of varying size, (real example from IOCP server). Try passing that by value..
9) Many OS calls cannot handle anything but a pointer. You cannot PostMessage, (that's a Windows API, for all you happy-feet), even a 256-byte structure by value with one call, (you have just the 2 wParam,lParam integers). Calls that set up asychronous callbacks often allow 'context data' to be sent to the callback - almost always just one pointer. Any app that is going to use such OS functionality is almost forced to resort to pass by reference.
Jeremy Friesner's comment seems to be the best as this is a new area, although Martin James's points are also good. I know Microsoft is looking into message passing for their future kernels as we gain more cores.
There seems to be a framework that deals with message passing and it claims to have much better performance than current .Net producer/consumer generics. I'm not sure how it will compare to .Net's Dataflow in 4.5
https://github.com/odeheurles/Disruptor-net
I am almost finished with my first monotouch app, almost that is, but for some big problems with memory leaks. Even though I override the viewDidUnload on every view controller so that for every UI element that I create I first remove it from its superview, then call Dispose and then set it to null, the problem persists. Using Instruments is no help, it doesn't detect the memory leaks and the memory allocations doesn't point me to anything that I can track.
My app uses mainly the MPMoviePlayer to play video streams and also displays an image gallery from images loaded through http. Both operation are causing problems.
Any ideas would be very much appreciated, thanks.
The Master is right of course. Gracias Miguel. I wanted though to give a more thorough explanation of what I did, with the hope that it may help future Xamarin colleges.
1) The MPMoviePlayer stores a video buffer which is kind of sticky. What I have done is have a unique instance running on the AppDelegate an reuse this across the views that show a video. So instead of initializing the MPMoviePlayerController with an url you use the constructor with no arguments, and then set the ContentUrl property and call Play().
2) Do not rely on ViewDidUnload being called to clean up you objects, because it is not called consistently. For example I use a lot of modal view controllers and this method never got called. Memory just kept accumulating until the app crashed. Better call you clean up code directly.
3) Images were the biggest memory hug I had. Even Images inside UIImageViews that were just used as background would never get disposed. I had to specifically call the following code on each image before I could clear up the memory:
myImageView.RemoveFromSuperview();
myImageView.Image.Dispose();
myImageView.Image = null;
myImageView.Dispose();
myImageView = null;
4) Beware of the UIWebView, it can hug a lot of memory, specially if there is some kind of AJAX interaction running on the page that you are loading. Calling the following code help a little but didn't solve all the problems. Some memory leaks remain that I wasn't able to get rid off:
NSString keyStr = new NSString("WebKitCacheModelPreferenceKey");
NSUserDefaults.StandardUserDefaults.SetValueForKey(NSObject.FromObject(val), keyStr);
5) If you can, avoid using Interface Builder. On several occasions I was never able to release UI elements created on the xib files. Positioning everything by hand can be a pain but if you are using a memory intensive application creating all your view controllers in code may be the way to go.
6) Using anonymous methods as event handlers is nice and my help code readability, but on some occasions not being able to manually detach an event handler became a problem. References to unwanted object remain in memory.
7) In my UITableViewSource I was able to have a more efficient memory handling by creating the UIImages that I use to style the cells independently and then just reusing them on my GetViewForHeader and GetCell methods.
One last thing; even though instruments is not really compatible with the way monotouch is doing things using the "Memory Monitor" was a valuable tool, if you are having problem it can indeed help.
These strategies solved most of my problems. Some may be pretty obvious in hindsight but I thought it wont hurt to pass them along.
Happy Coding and long live c# on the iPhone
The UI elements are not likely the responsible ones, those barely use any memory. And calling Dispose()/nulling helps, but only a tiny bit.
The more likely source of the problem are objects like the MPMoviePlayer, the image downloading and the image rendering. You might be keeping references to those objects which prevent the GC from getting rid of them.