Does it mean memory arena can not be shared between threads?
Will it aggravate memory fragment or even OOM?
Can it tell how much memory is held (but not allocated) by a thread?

• By default, the number of arena is four times of CPU cores. So currently, it's already nearly one arena per one thread. So I don't think it would aggravate memory fragment in TiKV case.

• What you mean by "held" is holding the memory allocated by other thread? Can't as allocator doesn't have the knowledge that the memory ownership is moved to another thread. At least, when it's freed in other threads, the memory usage accounted in the original allocated thread would be decreased.

Should we consider implementing a configuration switch to disable this feature, as a precautionary measure in case it triggers unforeseen issues?

According to the document, " There is a small fixed per-arena overhead, and additionally, arenas manage memory completely independently of each other, which means a small fixed increase in overall memory fragmentation. These overheads are not generally an issue, given the number of arenas normally used. Note that using substantially more arenas than the default is not likely to improve performance, mainly due to reduced cache performance. However, it may make sense to reduce the number of arenas if an application does not make much use of the allocation functions."

To make sure the overhead is small, can you run some read write mixed workload to compare the memory usage with and without this feature? @Connor1996

There are four rounds of sysbench tests, read_only, insert, write_only, read_write case respectively. And there is no noticeable difference in memory usage