While I’d followed Mr Toub and his gang while they were making the TPL, I’ve since slept and forgotten it all. So I can always consider a concurrent approach to my classes, I thought I’d make a very simple overview ‘cheat sheet’ and stick it to the wall.
Get it here.
Labels: concurrency, patterns, performance, programmingHow to list the memory being used in a .NET application, by type. This can be useful in finding memory usage problems (not always leaks in the strict sense). It's really pretty awful going back to commands and seeing pages of shitty numbers without comma digit grouping, but Microsoft seem not to care to produce a visual debugger.
Download the SDK for the version of Windows and the .NET Framework you have and install it.
Run your app.
Run WinDbg from the Start menu (search for WinDbg).
Start Task Manager and right-click the process and create a dump file. You can also attach to the process from WinDbg.
Drag and drop the .dmp file into the WinDbg shell.
Load the SOS.dll helper thingy using either one of the following commands in WinDbg. The first one instructs the debugger to load the DLL from the same folder as the mscorwks DLL was loaded from. The second is specific, check which version of the Framework your app runs under (I assume 4.0 for my app and forgot I hadn't upgraded it from 3.5).
.loadby sos mscorwks
.load c:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
Successful commands don't always give any feedback - no news is good news.
All going well, you should now be able to issue some commands to WinDbg and start analysing the app. Enter the following command:
!dumpheap –stat
If you get "Failed to find runtime DLL" (clr.dll), 0x80004005 then it can be because the wrong SOS.dll was loaded, run the command .unload on its own and it should unload it and you can try loading the right version again.
Otherwise a whole heap of stuff will spew out. Heap. See what I did there? Ordered by total bytes consumed, column 3, the biggest hoarder of memory should be last in the list. System.String usually.
Here are a bunch of links useful to this subject.
Tracking Memory Leaks - Rico Mariani
Memory Usage Auditing for .NET Applications
Labels: performance, programmingFollowing on from my last posting about the cost of running an Azure hosted little website I have done some more calculations.
As it turned out, my previous favourite, Fido.net had run out of servers and wanted more money than I was prepared to part with for the next rung up the server ladder.
Previously, I had toyed with the idea of running my own server. I can do this with Fido but they want me insured, and when I spoke to insurance people, they said that it was a waste of time as it would be incumbent on the OEM of the server that set fire to the building.
Redstation do co-lo and its cheap. You get a 100Mbit line and around 4Tb traffic cap, a 1U space in the rack and 8 IP addresses (5 usable), 24/7 access and free tea and coffee from the machine.
Couple them with a little server built here and I could be onto a sure fire value winner.
A custom PCN built 1U server with my own added reliable SSD drive will set me back $775. That's a quad core box with 8Gb RAM.
I can also load it up with my own BizSpark licensed software, which is not an option when you rent a server. Plus I can add another server some day and split out the SQL duties – although I’m getting ahead of myself.
Let's see how it all stacks up. Sorry for the micro text.
Unless I’m mistaken, and the point of a blog is much to do with airing thoughts so that others can give theirs, Windows Azure is exceptionally bad value.
I’m now using the Compute time as “time in existence” of the VM. And when the VMs are so puny, and the price is so large, 7p an hour for 1.6Ghz and 1.75Gb RAM, its not good.
When I first looked at Microsoft’s Azure platform, I thought it spelled the end for traditional hosters. Evidently not. I thought it was a low barrier to entry way for mobile app makers to get their apps into the cloud.
They have missed the opportunity to be truly disruptive in this market and charge a base rate plus the amount you use. Being MS, they own the OS and have the power to really accurately charge by utilisation, and auto provision at times or duress. At the moment, the value proposition is in the quick provisioning of servers and would benefit a company that gets massive influxes of traffic for short periods, like ticket sales.
Anyway, this is as much about Azure as it is about hosting options for a small website/service, and so it now looks like building a cheap server and paying for the rack space is the most cost-effective solution.
Until I sign a contract though, it could change. One thing that rented boxes provide is a little more peace of mind from driving down to the chilled room with a screwdriver at 2am. Although from my experience, hardware doesn’t fault that easily and its almost always a dodgy spindle.
With SSD drives, I hope to eliminate that.
Labels: frontiers, performance, programming, webAnother note-to-self style blog post in which I write down something that I seem to research and then forget the concrete answer some years later. This one is about the half-myth that events leak memory.
Failing to unsubscribe from events is bad because in some cases it keeps objects from being garbage collected. However, in closely integrated models of classes, it probably won't matter.
The following two UML models show how events may or may not leak.
On the left hand side, the Application object has a reference to a ViewModel class (the long line), which has a reference to the results of a service query. The ViewModel has subscribed to the CollectionChanged event on a collection exposed by the ServiceQueryResponse class.
Should the ViewModel reference be replaced or nulled in the application (the long line), then the entire object graph will become orphaned; an island to which no references tracks back to any executing code.
Thus, the GC will clean it up.
However, on the right, Application references an 'Other' object - perhaps a service proxy manager which caches the last query - which goes on to reference ServiceQueryResponse.If the ViewModel reference held by the Application object is nulled, then the ViewModel will not be collected due to the Target reference(s) in the delegates held by the CollectionChanged event.
Of course, if the Application object nulls out its reference to Other, then the whole lot will be collected and the heavyweight ViewModel will free its resources.
This is why I said that close-knit models, its not such a problem. If the events and references are all in a self-contained class or private unit of functionality, its likely that it will become an island.
Just writing this post has actually highlighted an issue I have with caching; my cache doesn't self clear, rather it replaces, so stuff can sit around for ages. And I cannot say for sure what chain of references the cached objects will be maintaining.
The blog post here is helpful in that the author attempts to solve the perceived problem (that doesn't exist) - read the comments.
And similarly on StackOverflow here.
Labels: performance, programmingMy personal notes from Jason Weber's session at MIX10. Essentially just a bulleted list of the 20 or so recommendations he made.
Living about 40 miles south of London, I am currently working from home on a personal project for the home media market.
My first programme was in BASIC when I was about 8, I then got into graphics on my 486, but real work began at Microsoft Product Support. I then worked at a big dot-com during the boom, then an investment bank.
I look like this...
