Memory usage higher than expected

[Dahrkael]

While running the test instance at extracker.dahrkael.net:6969 I noticed memory usage while not crazy (~3GB) was way higher than what was actually needed to store the actual data (~300MB for ~100k peers and ~100k swarms).
Investigating the matter I found out the default allocator strategy for ETS tables is not great for this use case (lots of tables with lots of changing records).

One easy solution is changing the strategy at startup from Address order first fit carrier best fit to either Address order best fit or Best fit.
When running through iex, just need to append --erl "+MEas aobf". This cuts down memory usage from ~3GB to ~500MB.

Relevant links about this:
https://www.erlang.org/doc/apps/erts/erts_alloc.html
https://erlang.org/pipermail/erlang-questions/2017-April/092056.html
https://stackoverflow.com/questions/49847782/erlang-ets-memory-fragmentation

This is something to take into account when the day of generating releases and docker images arrives.

[Dahrkael]

added +MEas aobf by default for releases in 7a30db6

[Dahrkael]

continuing with the high memory usage, I noticed allocating one ETS table for each swarm has an overhead of at least 3-6kb which is way more than what most swarms hold in peer storage.
So I've been refactoring how swarms are stored. Now all swarms below some threshold (100 peers by default) are pooled together in a fixed set of tables. This makes the overhead negligible and avoids RAM usage going higher and higher.
Big swarms (>100 peers) still get their own exclusive table to maintain performance.

Initial tests on the test instance show a memory usage reduction of 50% managing the same amount of peers and swarms as before, using a set of 100.000 fixed tables and a 100 peer limit.
More tests are needed to see how much I can reduce the set to save more RAM (defaults to 1000 tables, which should be around 5-10mb) without affecting performance.

[Dahrkael]

reduced the number of ranch acceptors for the HTTP routers to a more sane number and tried running with just 10.000 shared tables.
Memory usage went down 80% instead of 50%, which is great for more memory constrained machines, with a starting total usage of ~250mb.