Closed pliard-b closed 2 years ago
Hi. This might be addressed in blackbeam/mysql_async#170. I'm planning to port this for the next release.
Also I think that a flag that turns of the pool is the best option for your case, so I'll add it.
Thanks a lot @blackbeam for fixing this. We will give the pool another try with the crossbeam ArrayQueue. Disabling the pool through the environment variable seems a bit fragile though. Perhaps this could be done in the future via a cargo feature?
Disabling the pool through the environment variable seems a bit fragile though. Perhaps this could be done in the future via a cargo feature?
Agree. This is now addressed and will be in v22.0.0 release.
Disabling the pool through the environment variable seems a bit fragile though. Perhaps this could be done in the future via a cargo feature?
Agree. This is now addressed and will be in v22.0.0 release.
Great, thank you!
We have a Rust service that has thousands of threads using their own
mysql::Conn
to multiple databases. We noticed up to 10x CPU usage increases when going from mysql v20 to v21. The regression appears to be caused by contention on the added global buffer pool and the implementation ofstd::sync::Mutex
involving spinlocks (see below). FYI we are using jemalloc and theVec
allocations that the usage ofBufferPool
replaced didn't appear to be a bottleneck for us.Here are some suggestions that I can think of for how this can be addressed: 1) Revert to allocating
Vec
's on demandBufferPool
2) Make each
mysq::Conn
object have its own buffer3) Have
BufferPool
use a lock-free pool data structure such as what thepool
crate provides:pool
or the chosen alternative performsIn addition to these a hybrid approach could be used where a new flag controls whether 1-2) or 3) are used.