The system I work on can only be described as legacy crap. We are working to get it updated, the data consistent and to use NHibernate. NHibernate has been great in that the number of options available has given us the ability to work around some of the past ridiculous design choices. To that end we have been playing with/evaluating NHibernate Profiler.
I haven't used it that much, but some other members of the team regard it highly. So far to me it looks like a very nice piece of software.....if its not used on a legacy piece of $@!$. We have an application that runs as a windows service and is fired off ever 30 seconds. However the fun doesn't stop there. The service is replicated 7 times specifying the ID of the service on the command line. Its bunk, but it works. We've started using NHibernate hydrated POCO objects in this service. After about two hours the services would go berserk and use all the CPU. The version in production had a single usage of a NHibernate entity and seemed to work fine and forcing our CI server back to the production code stopped the services from going all Seppuku. It wasn't till I put 10-15 instances on my local dev box an dropped the service timer to 3 secs that I was able to recreate the issue locally.
Having10 instances of a service that want 100% cpu? Not fun. Took me a good while but, I was able to use Procces Explorer to set their priority to 'Below Normal' and get a usable system back. I attached the debugger and watched as it seemed to run just fine. My code was fine and I couldn't figure out what was going on. Then I looked at the threads and realized there were probably 30 threads trying to reset the NHProf logging. Woops. Until then I didn't realize that NHProf was the issue. If I were to actually start NHProf I could cause the berserk behavior at will.
So if you have alot of separate processes using NHibernate watch your use of NHProf. Like I said appears to be a sweet app, but you know what they say about crap in....
comments powered by Disqus