<div>The Multithread macros sounds great, </div>
<div>(I been following the emails for the past week)</div>
<div> </div>
<div>I was wondering, is the conversion to multithread going to behave the same on all/ most flavors or UNIX/Linux or does any special care needed for some distributions?</div>
<div> </div>
<div> </div>
<div>Tony<br><br></div>
<div class="gmail_quote">On Mon, Aug 24, 2009 at 11:37 AM, Steven D. Morrey <span dir="ltr"><<a href="mailto:smorrey@ldschurch.org">smorrey@ldschurch.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">The macro functions take almost no time.<br>The problem is one of trying to use shared mutable global memory.<br>
It's not a problem unless more than 1 thread is trying to access the macros at once.<br>Under that scenario thread A may delete a macro at the same time thread B is trying to read it.<br>This causes segfaulting I was seeing earlier.<br>
<br>It is possible that the macros, being originally designed to be global objects in a single threaded environment may end up in conflict with eachother.<br>If that's the case my refactor will allow us to quickly overcome that a well.<br>
<br>Sincerely,<br>Steve<br><br>________________________________________<br>From: Ton Voon [<a href="mailto:ton.voon@opsera.com">ton.voon@opsera.com</a>]<br>Sent: Saturday, August 22, 2009 12:48 AM<br>To: Nagios Developers List<br>
Subject: Re: [Nagios-devel] Multithreaded Macro Support wrapper proposal<br>
<div>
<div></div>
<div class="h5"><br>Hi Steven,<br><br>On 21 Aug 2009, at 18:35, Steven D. Morrey wrote:<br><br>> To that end I have decided to robustify the macro system by creating<br>> a handful of wrapper functions that will make the macros thread safe<br>
> (as long as all macro calls are passed through them).<br>> These functions are<br><br>Taking a different approach, which part of the macro setting routines<br>is taking the most time? My guess is that the summary macros takes the<br>
most time because it has to walk through the entire list of hosts and<br>services. <a href="http://nagios.sourceforge.net/docs/3_0/macrolist.html" target="_blank">http://nagios.sourceforge.net/docs/3_0/macrolist.html</a><br>
<br>You could disable summary macro processing with the large installation<br>tweaks (<a href="http://nagios.sourceforge.net/docs/3_0/largeinstalltweaks.html" target="_blank">http://nagios.sourceforge.net/docs/3_0/<br>largeinstalltweaks.html</a>) and see if the timings still show the macro<br>
portion to be causing the bottleneck. I think you are on Nagios 2<br>though, so this option is not available. You could try just commenting<br>out that entire block and see how it affects the profiling.<br><br>For Opsview, we found for a customer that their CPU was spinning at<br>
100%. Using strace, we found it was in the notifications logic setting<br>all the macro environment variables. But we knew that the customer<br>**didn't have notifications enabled for any contacts**. Turns out that<br>
when nagios got an alert event, it would set macros first, and then<br>work out if the contact should be notified. We changed the loop so<br>that it checked if the contact should be notified and then calculated<br>the macros. This reduced their CPU down to 10%.<br>
<br>Patch for Nagios 2.10: <a href="https://secure.opsera.com/svn/opsview/branches/BRAN-2.14/opsview-base/patches/nagios_reduce_notifications_load.patch" target="_blank">https://secure.opsera.com/svn/opsview/branches/BRAN-2.14/opsview-base/patches/nagios_reduce_notifications_load.patch</a><br>
<br>Patch for Nagios 3: <a href="https://secure.opsera.com/svn/opsview/branches/BRAN-3.1/opsview-base/patches/nagios_reduce_notifications_load.patch" target="_blank">https://secure.opsera.com/svn/opsview/branches/BRAN-3.1/opsview-base/patches/nagios_reduce_notifications_load.patch</a><br>
<br>I haven't put this into core code yet because I'm trying to work out a<br>way to test this. Even though I know this works for the thousands of<br>users using Opsview, I set myself a different standard when it comes<br>
to the hundreds of thousands of users of Nagios :)<br><br>I'd be grateful if anyone wants to write a libtap test that proves<br>this problem, so then I can get it applied to core code.<br><br>Ton<br><br><br>------------------------------------------------------------------------------<br>
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day<br>trial. Simplify your report design, integration and deployment - and focus on<br>what you do best, core application coding. Discover what's new with<br>
Crystal Reports now.  <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>_______________________________________________<br>Nagios-devel mailing list<br><a href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a><br><br><br></div></div>
<div class="im"> NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.<br>
<br><br><br>------------------------------------------------------------------------------<br></div>
<div>
<div></div>
<div class="h5">Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day<br>trial. Simplify your report design, integration and deployment - and focus on<br>what you do best, core application coding. Discover what's new with<br>
Crystal Reports now.  <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>_______________________________________________<br>Nagios-devel mailing list<br><a href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a><br></div></div></blockquote></div><br>