[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?
Miguel Angel Ajo Pelayo
mangelajo at redhat.com
Tue Jul 8 11:50:06 UTC 2014
I'd like to bring the attention back to this topic:
Mark, could you reconsider removing the -2 here?
https://review.openstack.org/#/c/93889/
Your reason was:
"""Until the upstream blueprint
(https://blueprints.launchpad.net/oslo/+spec/rootwrap-daemon-mode )
merges in Oslo it does not make sense to track this in Neutron.
"""
Given the new deadlines for the specs, I believe there is no
reason to finish the oslo side in a rush, but it looks like it's
going to be available during this cycle.
I believe it's something good which we may have available
during the juno cycle, as it's a very serious performance
penalty.
Best regards,
Miguel Ángel.
----- Original Message -----
>
>
> On 03/24/2014 07:23 PM, Yuriy Taraday wrote:
> > On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin <carl at ecbaldwin.net
> > <mailto:carl at ecbaldwin.net>> wrote:
> >
> > Don't discard the first number so quickly.
> >
> > For example, say we use a timeout mechanism for the daemon running
> > inside namespaces to avoid using too much memory with a daemon in
> > every namespace. That means we'll pay the startup cost repeatedly but
> > in a way that amortizes it down.
> >
> > Even if it is really a one time cost, then if you collect enough
> > samples then the outlier won't have much affect on the mean anyway.
> >
> >
> > It actually affects all numbers but mean (e.g. deviation is gross).
>
>
> Carl is right, I thought of it later in the evening, when the timeout
> mechanism is in place we must consider the number.
>
> >
> > I'd say keep it in there.
>
> +1 I agree.
>
> >
> > Carl
> >
> > On Mon, Mar 24, 2014 at 2:04 AM, Miguel Angel Ajo
> > <majopela at redhat.com <mailto:majopela at redhat.com>> wrote:
> > >
> > >
> > > It's the first call starting the daemon / loading config files,
> > > etc?,
> > >
> > > May be that first sample should be discarded from the mean for
> > all processes
> > > (it's an outlier value).
> >
> >
> > I thought about cutting max from counting deviation and/or showing
> > second-max value. But I don't think it matters much and there's not much
> > people here who're analyzing deviation. It's pretty clear what happens
> > with the longest run with this case and I think we can let it be as is.
> > It's mean value that matters most here.
>
> Yes, I agree, but as Carl said, having timeouts in place, in a practical
> environment, the mean will be shifted too.
>
> Timeouts are needed within namespaces, to avoid excessive memory
> consumption. But it could be OK as we'd be cutting out the ip netns
> delay. Or , if we find a simpler "setns" mechanism enough for our
> needs, may be we don't need to care about short-timeouts in ip netns
> at all...
>
>
> Best,
> Miguel Ángel.
>
>
> >
> > --
> >
> > Kind regards, Yuriy.
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list