Bug #6400

assign_interfaces.php issues with large numbers of interfaces

Added by wot wot 9 months ago. Updated 7 months ago.

Target version:
Start date:
Due date:
% Done:


Affected version:
Affected Architecture:


On a firewall running 2.3.1, after creating ~200 vlans, assign_interfaces.php gets very slow while taking 100% cpu. when selecting "assign interfaces" in the cli/console, a lot of "broken pipe" errors turn up before the usual config dialog begins.

I can help with debugging, the box in question however is in production.

1000-interface-config.xml Magnifier (230 KB) Chris Buechler, 07/11/2016 09:18 PM


#1 Updated by Luiz Otavio O Souza 9 months ago

  • Assignee set to Luiz Otavio O Souza

#2 Updated by Gareth Hay 8 months ago

We have been doing some testing on one of our sites.

Under 2.2.4 no issue with 100 vlans, under 2.3.1-RELEASE-p5 at 40 vlans it takes around 27 seconds to open the page on our boxes and it is noticibly slower as you add vlans one by one.

At 100 vlans we get a 504 Gateway time out.

nginx: 2016/06/23 12:08:23 [error] 17180#0: *134 upstream timed out (60: Operation timed out) while reading response header from upstream, client: X.X.X.X, server: , request: "GET /interfaces_assign.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "X.X.X.X", referrer: "https://X.X.X.X/".

This also happens under the i386 architecture.

Think this is the same as Bug #6520

#3 Updated by Phillip Davis 8 months ago

Maybe this is somehow related to
When submitting a change in interfaces_assign, interface_configure() is called, and that calls link_interface_to_vips() - the performance of which is improved by the change for 6515, in commit
It seems to me it would only help in a situation where there are a number of VIPs on the system, as well as a bunch of interfaces. So I am not sure that it is related, but would be worth applying the changes in that commit and see if anything improves.

#4 Updated by Chris Buechler 7 months ago

  • File 1000-interface-config.xmlMagnifier added
  • Subject changed from assign_interfaces throws "broken pipe" errors to assign_interfaces.php issues with large numbers of interfaces
  • Status changed from New to Confirmed
  • Target version changed from 2.3.2 to 2.4.0
  • Affected version changed from 2.3 to 2.3.x
  • Affected Architecture changed from amd64 to All

Not seeing any issues with 200 assigned interfaces (somewhat slower than 2.2.x, but still usable), but take it up to 1000 and assign_interfaces.php is non-functional. 504 timeout

example config attached.

2.3.2 is too near-term for significant changes, historically things along these lines have lead to regressions for the 99.99999% in interest of fixing the 0.00001%, so pushing this to 2.4.0.

Also available in: Atom PDF