[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