The documentation of eventlet.spawn_n says: "The same as spawn(), but it’s not possible to know how the function terminated (i.e. no return value or exceptions). This makes execution faster. See spawn_n for more details." I suspect that GreenPool.spaw_n may behave similarly.
It seems plausible that spawn_n is returning very quickly because of some error, and then all time is quickly spent in a short circuited while loop.
We ran into a case where the openvswitch agent (current master branch) eats 100% of CPU time.
Pyflame profiling show the time being largely spent in neutron. agent.linux. ip_conntrack, line 95.
https:/ /github. com/openstack/ neutron/ blob/master/ neutron/ agent/linux/ ip_conntrack. py#L95
The code around this line is:
while True:
pool. spawn_n( self._process_ queue)
The documentation of eventlet.spawn_n says: "The same as spawn(), but it’s not possible to know how the function terminated (i.e. no return value or exceptions). This makes execution faster. See spawn_n for more details." I suspect that GreenPool.spaw_n may behave similarly.
It seems plausible that spawn_n is returning very quickly because of some error, and then all time is quickly spent in a short circuited while loop.