This is not a mimalloc bug, but is an OS issue that affects mimalloc, so this ticket exists as a note to help anyone who might run into the same thing.
It has been observed that release 2.1.2 when run on a large, heavily-loaded service on Windows Server 2019 will incur a high percentage of system CPU time (e.g. 95%). The 2.0.7 release does not do this. This results in a ~3x performance degradation for the workload.
Fortunately, the fix exists and is just to use Windows Server 2022 rather than 2019. 2022 performs the load just fine.
Some details about the load in question: multi-threaded single-process service, ~150-400GB of memory (out of 1TB), 16-32 CPUs all saturated. The service creates many short-lived threads that may allocate a lot of memory (e.g. 1-20GB).
Something in the scheme new to 2.1.2 clearly tickles 2019 the wrong way. Note that I'm making the assumption that it's specific to 2.1.2, but it actually could be earlier since the releases between 2.0.7 and 2.1.2 were not tested.
Hi,
This is not a mimalloc bug, but is an OS issue that affects mimalloc, so this ticket exists as a note to help anyone who might run into the same thing.
It has been observed that release 2.1.2 when run on a large, heavily-loaded service on Windows Server 2019 will incur a high percentage of system CPU time (e.g. 95%). The 2.0.7 release does not do this. This results in a ~3x performance degradation for the workload.
Fortunately, the fix exists and is just to use Windows Server 2022 rather than 2019. 2022 performs the load just fine.
Some details about the load in question: multi-threaded single-process service, ~150-400GB of memory (out of 1TB), 16-32 CPUs all saturated. The service creates many short-lived threads that may allocate a lot of memory (e.g. 1-20GB).
Something in the scheme new to 2.1.2 clearly tickles 2019 the wrong way. Note that I'm making the assumption that it's specific to 2.1.2, but it actually could be earlier since the releases between 2.0.7 and 2.1.2 were not tested.