connection_pool: fix excessive idle CPU usage while waiting for requests#336
Conversation
oleg-jukovec
left a comment
There was a problem hiding this comment.
Please, update the commit message (see above) and add a new entry to the CHANGELOG.md.
|
I had to update the build os version for the readthedocs to 24.04, as it stopped supporting 20.04. 24.04 was selected based on a similar version update in #330. |
|
I checked failed jobs on CI. Windows system jobs fail because the default version of setuptools is 65.5.0 in the CI image. When dependencies are installed in a step, setuptools updates to the latest version 82.0.1 which meets the requirements of In Linux, a jobs that use the master Tarantool branch fail because the maximum decimal precision has been increased to 76 in Tarantool 3.5. tarantool/tarantool#11497. I can try to fix this in the implementation of the decimal type for msgpack. Should I make these changes in this pull request? |
|
I decided to have a separate PR(#342) for the CI fix because there are a lot of changes related to the new decimal precision. Could you check this PR please? After it we will be able to successfully finish workflow in this PR. |
|
Thanks for the patch! |
While using
ConnectionPool, it was found that it uses 100% cpu for its threads when at rest. After examining its operation, it was realized that the_request_process_loopruns in an infinite loop, without blocking on waiting for the next request. To reduce the load, I suggest using already implemented wait for the next element in the queue's from packagequeue.To check the solution, I implemented a simple test that calculates the n-th element of the Fibonacci sequence using a
ConnectionPoolrunning in the background:I ran the test with the changes and the old ConnectionPool behavior. So i got the following test results:

I also looked at the distribution of processor activity using py-spy for each of the tests:
As you can see from the py-spy snapshots, after the change, the processor is almost fully used for calculating Fibonacci sequence, while with the current behavior, most of the time is spent on
_request_process_loop.