This is very similar to IPAM... There is a space of possible ids or addresses that can grow very large. We need to track the allocation of individual ids or addresses from that space and be able to quickly come up with a new allocations and recycle old ones. I've had this in the back of my mind for a week or two now.
A similar problem came up when the database would get populated with the entire free space worth of ip addresses to reflect the availability of all of the individual addresses. With a large space (like an ip4 /8 or practically any ip6 subnet) this would take a very long time or never finish. Neutron was a little smarter about this. It compressed availability in to availability ranges in a separate table. This solved the original problem but is not problem free. It turns out that writing database operations to manipulate both the allocations table and the availability table atomically is very difficult and ends up being very slow and has caused us some grief. The free space also gets fragmented which degrades performance. This is what led me -- somewhat reluctantly -- to change how IPs get recycled back in to the free pool which hasn't been very popular. I wonder if we can discuss a good pattern for handling allocations where the free space can grow very large. We could use the pattern for the allocation of both IP addresses, VXlan ids, and other similar resource spaces. For IPAM, I have been entertaining the idea of creating an allocation agent that would manage the availability of IPs in memory rather than in the database. I hesitate, because that brings up a whole new set of complications. I'm sure there are other potential solutions that I haven't yet considered. The L3 subteam is currently working on a pluggable IPAM model. Once the initial framework for this is done, we can more easily play around with changing the underlying IPAM implementation. Thoughts? Carl On Thu, May 29, 2014 at 4:01 AM, Xurong Yang <ido...@gmail.com> wrote: > Hi, Folks, > > When we configure VXLAN range [1,16M], neutron-server service costs long > time and cpu rate is very high(100%) when initiation. One test base on > postgresql has been verified: more than 1h when VXLAN range is [1, 1M]. > > So, any good solution about this performance issue? > > Thanks, > Xurong Yang > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
