yahoo-eng-team team mailing list archive

[Lan Qi song <lqslan@xxxxxxxxxx>]

Public bug reported:

This issue is introducing a performance problem for the L2 agent
including LinuxBridge and OVS agent in Compute node when there are lots
of networks and instances in this Compute node (eg. 500 instances)

The performance problem reflect in two aspects:

1. When LinuxBridge agent service starts up(this seems only happened in
LinuxBridge agent not for the OVS agent), I found there were two methods
take too much time:

   1.1 get_interface_by_ip(),  we should find the interface which was
assigned with the "local ip" defined in configuration file, and to check
whether this interface support "vxlan" or not.  This method will iterate
all the interface in this compute node and execute "ip link show
[interface] to [local  ip]" to judge the result.  I think there should
be a faster way.

   1.2 prepare_port_filter() ,  in this method ,  we should make sure
the ipset are create correctly. But this method will execute too much
"ipset" commands and take too much time.

2. When devices' sg rules are changed,  L2 agent should refresh the
firewalls.

    2.1 refresh_firewall() this method will call "modify_rules" to make
the rules predicable, but this method also takes too much time.

It will be very benefit for the large scales of networks if this
performance problem can be fix or optimize.

** Affects: neutron
     Importance: Undecided
         Status: New

** Description changed:

  This issue is introducing a performance problem for the L2 agent
  including LinuxBridge and OVS agent in Compute node when there are lots
  of networks and instances in this Compute node (eg. 500 instances)
  
  The performance problem reflect in two aspects:
  
  1. When LinuxBridge agent service starts up(this seems only happened in
  LinuxBridge agent not for the OVS agent), I found there were two methods
  take too much time:
  
-    1.1 get_interface_by_ip(),  we should find the interface which was
+    1.1 get_interface_by_ip(),  we should find the interface which was
  assigned with the "local ip" defined in configuration file, and to check
  whether this interface support "vxlan" or not.  This method will iterate
  all the interface in this compute node and execute "ip link show
  [interface] to [local  ip]" to judge the result.  I think that should be
  a faster way.
  
-    1.2 prepare_port_filter() ,  in this method ,  we should make sure
+    1.2 prepare_port_filter() ,  in this method ,  we should make sure
  the ipset are create correctly. But this method will execute too much
  "ipset" commands and take too much time.
  
+ 2. When devices' sg rules are changed,  L2 agent should refresh the
+ firewalls.
  
- 2. When devices' sg rules are changed,  L2 agent should refresh the firewalls.
- 
-     2.1 refresh_firewall() this method will call "modify_rules" to make
+     2.1 refresh_firewall() this method will call "modify_rules" to make
  the rules predicable, but this method also takes too much time.
  
  It will be very benefit for the large scales of networks if this
  performance problem can be fix or optimize.
- 
- 
- If this kind of performance problem

** Description changed:

  This issue is introducing a performance problem for the L2 agent
  including LinuxBridge and OVS agent in Compute node when there are lots
  of networks and instances in this Compute node (eg. 500 instances)
  
  The performance problem reflect in two aspects:
  
  1. When LinuxBridge agent service starts up(this seems only happened in
  LinuxBridge agent not for the OVS agent), I found there were two methods
  take too much time:
  
     1.1 get_interface_by_ip(),  we should find the interface which was
  assigned with the "local ip" defined in configuration file, and to check
  whether this interface support "vxlan" or not.  This method will iterate
  all the interface in this compute node and execute "ip link show
- [interface] to [local  ip]" to judge the result.  I think that should be
- a faster way.
+ [interface] to [local  ip]" to judge the result.  I think there should
+ be a faster way.
  
     1.2 prepare_port_filter() ,  in this method ,  we should make sure
  the ipset are create correctly. But this method will execute too much
  "ipset" commands and take too much time.
  
  2. When devices' sg rules are changed,  L2 agent should refresh the
  firewalls.
  
      2.1 refresh_firewall() this method will call "modify_rules" to make
  the rules predicable, but this method also takes too much time.
  
  It will be very benefit for the large scales of networks if this
  performance problem can be fix or optimize.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1499177

Title:
  Performance: L2 agent takes too much time to refresh sg rules

Status in neutron:
  New

Bug description:
  This issue is introducing a performance problem for the L2 agent
  including LinuxBridge and OVS agent in Compute node when there are
  lots of networks and instances in this Compute node (eg. 500
  instances)

  The performance problem reflect in two aspects:

  1. When LinuxBridge agent service starts up(this seems only happened
  in LinuxBridge agent not for the OVS agent), I found there were two
  methods take too much time:

     1.1 get_interface_by_ip(),  we should find the interface which was
  assigned with the "local ip" defined in configuration file, and to
  check whether this interface support "vxlan" or not.  This method will
  iterate all the interface in this compute node and execute "ip link
  show [interface] to [local  ip]" to judge the result.  I think there
  should be a faster way.

     1.2 prepare_port_filter() ,  in this method ,  we should make sure
  the ipset are create correctly. But this method will execute too much
  "ipset" commands and take too much time.

  2. When devices' sg rules are changed,  L2 agent should refresh the
  firewalls.

      2.1 refresh_firewall() this method will call "modify_rules" to
  make the rules predicable, but this method also takes too much time.

  It will be very benefit for the large scales of networks if this
  performance problem can be fix or optimize.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1499177/+subscriptions