Re: [Nagios-devel] Multithreaded Macro Support wrapper proposal
Nagios network monitoring software is enterprise server monitoring
Brought to you by:
egalstad,
sawolf-nagios
From: Anthony M. <amo...@gm...> - 2009-08-25 02:20:09
|
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 <sm...@ld...>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...@op...] > 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 > Nag...@li... > 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 > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-devel > |