NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Caveats for using high debug levels when investigating an issue

Posted by Preston on 2009-06-22

Or, remember quantum physics.

There’s a basic rule of quantum physics, that being the observer effect – the more you watch something, the more likely you are to impact that thing you are watching*.

The observer effect plays out quite a lot in IT, and I like to remind people that it also comes into effect when using NetWorker. However, that’s not just a “Murphy’s law” style scenario where you if spend 3 hours trying to debug a problem and then ask someone to have a look at it, it magically disappears.

No, it’s also the scenario of trying to watch an error condition in debug mode only to find it vanish. Now, this doesn’t happen all the time, but it is likely to happen in certain scenarios, such as race conditions. When you have a race condition, the observer effect can definitely come into play.

Consider it this way – when NetWorker is running without any debug mode enabled, it’s pumping through its tasks as fast as the overall environment (including its own coding) will allow it to complete.

However, when you put NetWorker into debug mode, it has to interrupt its normal flow more often to spit out additional information about what it is doing, what feedback it is getting, and so on. That’s feedback and output that it ordinarily wouldn’t have to deal with. That is, you’re artificially slowing down the run-time of the product. If NetWorker is experiencing a problem that is timing or sequence related, the slowing down of NetWorker may result in the condition being avoided.

Thus, when debugging NetWorker (i.e., putting it into debug mode for extended analysis), it’s reasonably important that you:

  • Start at a low number (e.g., 3, or 9 at the most);
  • Determine whether the problem still occurs;
  • If the problem does still occur but you don’t get enough information, increase debug levels incrementally;
  • If the problem does not occur, decrease the debug levels by “half at a time” (or as close to as possible) and note when the error reappears.

Or more precisely – if planning on using debug mode, don’t just jump in and set it to a ridiculously high number. Not only will it produce vast amounts of logs for you to wade through, it also has the potential of preventing the error from happening at all, which just puts you back to square 1.


* Strangely enough, owners of cats may also be well aware of this. The more you stare at a cat, the more likely it is to stop what it’s doing and react.

Advertisements

Sorry, the comment form is closed at this time.

 
%d bloggers like this: