<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:宋体;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">This patch packages 500 DB ‘add’ operations into 1.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">And in my own test, time costed reduces from 90s to 30s. boost!<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">/Yalei<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:enikanorov@mirantis.com]
<br>
<b>Sent:</b> Thursday, June 05, 2014 4:37 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">We hijacked the vxlan initialization performance thread with ipam! :)<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">I've tried to address initial problem with some simple sqla stuff: <a href="https://review.openstack.org/97774">https://review.openstack.org/97774</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">With sqlite it gives ~3x benefit over existing code in master.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Need to do a little bit more testing with real backends to make sure parameters are optimal.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Eugene.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Thu, Jun 5, 2014 at 12:29 AM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:<o:p></o:p></span></p>
<p><span lang="EN-US">Yes, memcached is a candidate that looks promising. First things first, though. I think we need the abstraction of an ipam interface merged. That will take some more discussion and work on its own.<o:p></o:p></span></p>
<p><span lang="EN-US" style="color:#888888">Carl<o:p></o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On May 30, 2014 4:37 PM, "Eugene Nikanorov" <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">> </span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial","sans-serif"">I was thinking it would be a separate process that would communicate over the RPC channel or something.</span><span lang="EN-US"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif"">memcached?</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Arial","sans-serif"">Eugene.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Sat, May 31, 2014 at 2:27 AM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Eugene,<br>
<br>
That was part of the "whole new set of complications" that I<br>
dismissively waved my hands at. :)<br>
<br>
I was thinking it would be a separate process that would communicate<br>
over the RPC channel or something. More complications come when you<br>
think about making this process HA, etc. It would mean going over RPC<br>
to rabbit to get an allocation which would be slow. But the current<br>
implementation is slow. At least going over RPC is greenthread<br>
friendly where going to the database doesn't seem to be.<br>
<span style="color:#888888"><br>
Carl</span><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
On Fri, May 30, 2014 at 2:56 PM, Eugene Nikanorov<br>
<<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br>
> Hi Carl,<br>
><br>
> The idea of in-memory storage was discussed for similar problem, but might<br>
> not work for multiple server deployment.<br>
> Some hybrid approach though may be used, I think.<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Fri, May 30, 2014 at 8:53 PM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:<br>
>><br>
>> This is very similar to IPAM... There is a space of possible ids or<br>
>> addresses that can grow very large. We need to track the allocation<br>
>> of individual ids or addresses from that space and be able to quickly<br>
>> come up with a new allocations and recycle old ones. I've had this in<br>
>> the back of my mind for a week or two now.<br>
>><br>
>> A similar problem came up when the database would get populated with<br>
>> the entire free space worth of ip addresses to reflect the<br>
>> availability of all of the individual addresses. With a large space<br>
>> (like an ip4 /8 or practically any ip6 subnet) this would take a very<br>
>> long time or never finish.<br>
>><br>
>> Neutron was a little smarter about this. It compressed availability<br>
>> in to availability ranges in a separate table. This solved the<br>
>> original problem but is not problem free. It turns out that writing<br>
>> database operations to manipulate both the allocations table and the<br>
>> availability table atomically is very difficult and ends up being very<br>
>> slow and has caused us some grief. The free space also gets<br>
>> fragmented which degrades performance. This is what led me --<br>
>> somewhat reluctantly -- to change how IPs get recycled back in to the<br>
>> free pool which hasn't been very popular.<br>
>><br>
>> I wonder if we can discuss a good pattern for handling allocations<br>
>> where the free space can grow very large. We could use the pattern<br>
>> for the allocation of both IP addresses, VXlan ids, and other similar<br>
>> resource spaces.<br>
>><br>
>> For IPAM, I have been entertaining the idea of creating an allocation<br>
>> agent that would manage the availability of IPs in memory rather than<br>
>> in the database. I hesitate, because that brings up a whole new set<br>
>> of complications. I'm sure there are other potential solutions that I<br>
>> haven't yet considered.<br>
>><br>
>> The L3 subteam is currently working on a pluggable IPAM model. Once<br>
>> the initial framework for this is done, we can more easily play around<br>
>> with changing the underlying IPAM implementation.<br>
>><br>
>> Thoughts?<br>
>><br>
>> Carl<br>
>><br>
>> On Thu, May 29, 2014 at 4:01 AM, Xurong Yang <<a href="mailto:idopra@gmail.com" target="_blank">idopra@gmail.com</a>> wrote:<br>
>> > Hi, Folks,<br>
>> ><br>
>> > When we configure VXLAN range [1,16M], neutron-server service costs long<br>
>> > time and cpu rate is very high(100%) when initiation. One test base on<br>
>> > postgresql has been verified: more than 1h when VXLAN range is [1, 1M].<br>
>> ><br>
>> > So, any good solution about this performance issue?<br>
>> ><br>
>> > Thanks,<br>
>> > Xurong Yang<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>