On 9/3/26 12:07 AM, Aeliton G. Silva wrote: > Commit 6de8868d (reconnect: Fix broken inactivity probe if there is no > other reason to wake up.) enables poll_loop to run immediately on the > next millisecond when the probe interval has expired with no receive > attempted. Its reasoning notes that "in a correctly written application > we should not fall into this case more than once in a row". > > The problem. An ovsdb-server session whose peer stops reading falls into > it forever, causing the ovsdb-server process to burn CPU proportionally > to the number of sessions. This behaviour has been observed in > production, where a few ovn-octavia-provider clients raised an exception > but did not die, keeping their backlog frozen and degrading the > ovsdb-server service. > > The loop spins[1] from the moment the first interval expires -- here > t+8 s with the 5 s default, t+201 s with a 180 s probe -- and the cost > grows with the session count, because every wake-up walks every > connection: 10.5% of a core with the stalled session alone, 21.9% > alongside 50 healthy sessions, 42.3% alongside 300. Killing the stalled > sessions returns the pass rate and the CPU to baseline at once, which is > what separates the pin from load. > > A merely slow consumer arms the same pin. ovsdb-server sees only its > own queue shrinking, and that happens only when the kernel accepts more > data -- which depends on the peer acknowledging what it already has, not > on the peer reading each byte. The 4 kB/s row below is such a peer. > > ovsdb-server has no way to know this happened: a session with a standing > backlog does not have jsonrpc_session_recv() invoked
Hmm. It soends like this patch is trying to fix the wrong problem. If we're actually never calling the recv() on a connection, that is likely what we should be addressing instead of inventing workarounds. And this should natuarally disconnect clients that do not respond to inactivity probes. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
