Use Jemalloc allocator

[mstrug]

Description

Basing on test results (link) of using custom allocators on Staging environment, applied jemalloc allocator as it uses the least memory.

Changes

Removed mimalloc dependency. Added dedicated macro use_custom_global_allocator!() in shared crate, which declares Jemalloc as Rust global allocator. This macro is used all executables.

How to test

Verify Grafana metrics after longer usage of jemalloc to verify if there is no regression comparing to mimalloc.

[m-lord-renkse]

Besides staging, was it tested in production for any network? I am mostly curious, traffic isn't the same in staging and prod 🤔 is there a testing plan for this before the final merge?

[mstrug]

Besides staging, was it tested in production for any network? I am mostly curious, traffic isn't the same in staging and prod 🤔 is there a testing plan for this before the final merge?

No, it wasn't tested in our production environment. From Grafana briefly I see the memory usage of Arbitrum One prod network is on similar level as for Staging mainnet.
Also jemalloc library has long development history and is used as FreeBSD default memory allocator and by some services in Facebook, Firefox (according to this site), so from stability point of view it should work fine.
What options regarding testing on prod we have? Should it be firstly deployed to Sepolia, then to Arbitrum/Gnosis and finally Mainnet?

[squadgazzz]

I tested it previously on prod, but before merging it, we should definitely try this again on mainnet prod. Because my tests were under different circumstances. Since I am on-call this week, I can do that once I have time. The behavior on prod is completely different from staging due to a much higher load.

[squadgazzz]

Based on the latest prod run, this allocator is not suggested to be used(at least for the orderbook and driver-liquidity).

upd: make is required to be added to the Docker file build section.

[mstrug]

Closing, as current results on prod suggest regression.