Multithreaded Macro Support wrapper proposal
Anthony Montibello
amontibello at gmail.com
Tue Aug 25 04:19:55 CEST 2009
The Multithread macros sounds great,
(I been following the emails for the past week)
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?
Tony
On Mon, Aug 24, 2009 at 11:37 AM, Steven D. Morrey <smorrey at ldschurch.org>wrote:
> The macro functions take almost no time.
> The problem is one of trying to use shared mutable global memory.
> It's not a problem unless more than 1 thread is trying to access the macros
> at once.
> Under that scenario thread A may delete a macro at the same time thread B
> is trying to read it.
> This causes segfaulting I was seeing earlier.
>
> 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.
> If that's the case my refactor will allow us to quickly overcome that a
> well.
>
> Sincerely,
> Steve
>
> ________________________________________
> From: Ton Voon [ton.voon at opsera.com]
> Sent: Saturday, August 22, 2009 12:48 AM
> To: Nagios Developers List
> Subject: Re: [Nagios-devel] Multithreaded Macro Support wrapper proposal
>
> Hi Steven,
>
> On 21 Aug 2009, at 18:35, Steven D. Morrey wrote:
>
> > To that end I have decided to robustify the macro system by creating
> > a handful of wrapper functions that will make the macros thread safe
> > (as long as all macro calls are passed through them).
> > These functions are
>
> Taking a different approach, which part of the macro setting routines
> is taking the most time? My guess is that the summary macros takes the
> most time because it has to walk through the entire list of hosts and
> services. http://nagios.sourceforge.net/docs/3_0/macrolist.html
>
> You could disable summary macro processing with the large installation
> tweaks (http://nagios.sourceforge.net/docs/3_0/
> largeinstalltweaks.html) and see if the timings still show the macro
> portion to be causing the bottleneck. I think you are on Nagios 2
> though, so this option is not available. You could try just commenting
> out that entire block and see how it affects the profiling.
>
> For Opsview, we found for a customer that their CPU was spinning at
> 100%. Using strace, we found it was in the notifications logic setting
> all the macro environment variables. But we knew that the customer
> **didn't have notifications enabled for any contacts**. Turns out that
> when nagios got an alert event, it would set macros first, and then
> work out if the contact should be notified. We changed the loop so
> that it checked if the contact should be notified and then calculated
> the macros. This reduced their CPU down to 10%.
>
> Patch for Nagios 2.10:
> https://secure.opsera.com/svn/opsview/branches/BRAN-2.14/opsview-base/patches/nagios_reduce_notifications_load.patch
>
> Patch for Nagios 3:
> https://secure.opsera.com/svn/opsview/branches/BRAN-3.1/opsview-base/patches/nagios_reduce_notifications_load.patch
>
> I haven't put this into core code yet because I'm trying to work out a
> way to test this. Even though I know this works for the thousands of
> users using Opsview, I set myself a different standard when it comes
> to the hundreds of thousands of users of Nagios :)
>
> I'd be grateful if anyone wants to write a libtap test that proves
> this problem, so then I can get it applied to core code.
>
> Ton
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
>
> 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.
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20090824/6da429e7/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel
More information about the Developers
mailing list