# Is Jemalloc still recommended to replace glibc? **URL:** \ **Category:** Percona Server for MySQL 5.7\ **Created:** [August 20, 2026, 2:50am UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183 "2026-08-20T02:50:45Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![minh](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@minh](https://forums.percona.com/u/minh)\ **Post date:** [August 20, 2026, 2:50am UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/1 "2026-08-20T02:50:45Z")
We have Percona MySQL 5.7 running on AWS EC2 with 752 GB of memory and 128 CPUs, using Rocky 8. We typically see around 36K QPS during peak times, with approximately 20–40 running threads. However, we have experienced outages when the number of running threads increased to over 1,000. At that point, every query became slower, and we saw hundreds of threads appear to be in the “freeing item” state, although the majority of queries still completed within one second. When we throttled the traffic, the system recovered almost immediately. We understand that this is load-related and that the database is reaching a tipping point. We found some older information suggesting that jemalloc may handle high concurrency better than glibc and that we could use jemalloc to replace glibc. However, most of this information dates back almost 10 years. We also don’t see memory usage increasing consistently. What would be a good indicator that we should consider replacing glibc with jemalloc? ---
**Author:** ![kedarpercona](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/kedarpercona/32/809_2.png) [@kedarpercona](https://forums.percona.com/u/kedarpercona)\ **Post date:** [August 20, 2026, 10:42am UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/2 "2026-08-20T10:42:38Z")
Hi @minh , Welcome to Percona Community. So the problem here is “at high active threads, the query becomes slower” and processlist shows “freeing items” state. I’d disable query cache. (do test) ```auto set global query_cache_size=0; set global query_cache=OFF; ``` This is more of a problem at concurrency than at memory, as you clearly state that you don’t see memory usage increase! We might want to look at overall query pattern and other configuration as well! Eg. there is low table cache and your queries are making multi table joins - with high concurrency it could be a problem. Anyways, to answer your other question, I have a counter. “most of this information dates back almost 10 years” - Yes, but then the engine you’re using is also decade old. If your doubt is on memory, that’s a recommended solution. But wait… here is your next question “What would be a good indicator that we should consider replacing glibc with jemalloc?” - a good indicator as a proof will be us proving it that the majority of your time is spent for memory specific ops and not innodb internals/query cache/disk tables… There is this article that elaborates on [how to identify scaling issues](https://percona.community/blog/2020/02/05/finding-mysql-scaling-problems-using-perf/). Thanks, K ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [August 20, 2026, 8:24pm UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/3 "2026-08-20T20:24:40Z")
> [@minh](#): > > However, most of this information dates back almost 10 years. Well, yea, 5.7 died, like completely died, a long time ago. Even 8.0 is pretty well dead. Curious, why are you trying to fix something that has no support, and no updates? > [@minh](#): > > number of running threads increased to over 1,000. Have you tried the thread\_pool plugin? This is designed specifically to handle high active thread count environments. > [@minh](#): > > We also don’t see memory usage increasing consistently. What would be a good indicator that we should consider replacing glibc with jemalloc? jemalloc is a memory allocator/manager. If you are not seeing mysqld holding on to memory for extended periods of time, then you don’t necessarily need jemalloc. Will it hurt to use it? Probably not. ---
**Author:** ![minh](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@minh](https://forums.percona.com/u/minh)\ **Post date:** [August 20, 2026, 11:41pm UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/4 "2026-08-20T23:41:13Z")
We understand that MySQL 5.7 is EOL. We’re moving to MySQL 8; it just takes time. This outage happened on MySQL 5.7. Our production environment is OLTP, but there are some long-running queries. With `thread_pool`, I assume queue scheduling could be challenging and may need to be adjusted based on the traffic pattern. Due to the outage, I was advised to look into jemalloc, which is supposed to handle memory allocation better than glibc. The “freeing items” state may be related to memory allocation, so if jemalloc is faster than glibc, it could potentially improve our throughput. I was told that jemalloc is very popular and has been adopted by many Percona MySQL customers. I don’t think using jemalloc would hurt, but adopting a third-party library does add maintenance overhead for us. Therefore, I’m looking for opinions on how the Percona MySQL community views the use of jemalloc. ---
**Author:** ![dogs\_Cute](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/dogs_cute/32/12754_2.png) [@dogs\_Cute](https://forums.percona.com/u/dogs_Cute)\ **Post date:** [August 21, 2026, 8:17am UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/5 "2026-08-21T08:17:30Z")
Based on the current information, I would not recommend changing the memory allocator yet. The evidence clearly shows a high-concurrency scalability problem, but it does not identify the root cause. The `freeing item` state and stable memory usage are not sufficient evidence of glibc allocator contention. ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [August 21, 2026, 3:33pm UTC](https://forums.percona.com/t/is-jemalloc-still-recommended-to-replace-glibc/41183/6 "2026-08-21T15:33:51Z")
> [@minh](#): > > We’re moving to MySQL 8; it just takes time How much time do you need? 🙂 MySQL 5.7 has been dead for at least 6 years. I’ve upgraded many customers from 50GB to 10TB to MySQL 8 with zero downtime. Create a new MySQL 8.4 server (with a modern OS like Rocky 9 or Ubuntu 24). Restore a backup. Configure replication. Wait for catchup, then switch apps to new IP. That might take 1 day depending on the data size. You should skip 8.0 and go straight to 8.4, otherwise you’re upgrading from “really dead software” to “dead software”. 8.4 isn’t even the current GA, 9.7 is. And MySQL 26.7 was released, last month. There is also a 99% chance that by simply upgrading to a modern MySQL, this issue you are experiencing will be solved due to all the improvements in memory, and connection management. This is why we **always** recommend upgrading before making any configuration changes or introducing something new. > [@minh](#): > > I was told that jemalloc is very popular and has been adopted by many Percona MySQL customers. Very true, and we do recommend it. There is no harm in using it. > [@minh](#): > > does add maintenance overhead for us I’m not sure what “overhead” you’re referring to. It’s installed as a system library via apt/dnf, so it’ll take a few seconds to install and restart MySQL. After that, nothing to worry about. Install jemalloc, try it out for a week. If things don’t improve, then give the thread\_pool plugin a try.