pcp
[Top] [All Lists]

[Bug 1323521] remote operation of pmie based pmda restarter interferes w

To: pcp@xxxxxxxxxxx
Subject: [Bug 1323521] remote operation of pmie based pmda restarter interferes with local pmcd
From: bugzilla@xxxxxxxxxx
Date: Sun, 10 Apr 2016 22:35:21 +0000
Auto-submitted: auto-generated
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <bug-1323521-355098@xxxxxxxxxxxxxxxxxxx>
References: <bug-1323521-355098@xxxxxxxxxxxxxxxxxxx>
https://bugzilla.redhat.com/show_bug.cgi?id=1323521

Nathan Scott <nathans@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mbenitez@xxxxxxxxxx
           Assignee|nathans@xxxxxxxxxx          |fche@xxxxxxxxxx



--- Comment #6 from Nathan Scott <nathans@xxxxxxxxxx> ---
(In reply to Frank Ch. Eigler from comment #4)
> > > [...]  Have you tested this scenario before making this assertion?
> > > [...]  avoid paying its performance cost
> > 
> > You seem to be asking me to prove that that a hypothetical bug you've opened
> > exists.  However, I see no evidence of a problem, nor would I expect to, so
> > I tend to think we should spend time on more worthwhile pursuits.
> 
> The bug plainly exists in the current code.  A large-fanout central pmie
> server will [...]

Why would the remote collectors exhibiting this problem not be able to run a
local pmie alongside their problematic pmcd/pmdas?  They are able to, of
course, so this fan-out-with-all-failing case is an unrealistic scenario.

> flood its own local pmcd with SIGHUPS, 1 per minute per remote server.

For this to be even close-to-maybe-remotely-a-problem, it assumes:
- all/many remote servers have failed agents, constantly
- all remote servers are not (able to?) run local pmie (why not?)
- or, all/many remote servers have an inability to restart agents
- it can't be solved in pmmgr/pmlogger_check (it can, as per BZ 1323851)

I have spent alot of time in this code - the cost of a no-op SIGHUP to pmcd is
not measurable (not even if multiplied by 1000s of hypothetically broken remote
servers that for some bizarre reason cannot run local pmie co-processes).

> > > Hand-editing default configuration files is not helpful advice, esp. [...]
> > 
> > Oh, a misunderstanding perhaps - this is all pmieconf-driven, there's no
> > hand-editing involved here.
> 
> The point is that you suggested editing the pmieconf-generated files to
> remove the useless & possibly-harmful pmsignal clause.  That is an
> impractical solution.

At no point did I suggest editing the pmieconf-generated-files via anything
other than an automated process - pmmgr could certainly run pmieconf to disable
this rule if its still concerning you, as I already said.  So, very much a
practical approach if you are concerned about this in pmmgr.

Also, as I said, I'm not against further work in the area and/or additional
solutions ... please do hack on it if you wish.  IMO though, this problem is
adequately solved by the simpler pmie solution.

Thanks for your interest!  Let me know if/when you have code for some other,
additional approach, and I'll be happy to review and assess it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=Mu9LX62SlE&a=cc_unsubscribe
<Prev in Thread] Current Thread [Next in Thread>