Michal Kuratczyk

I've re-tested with [the most recent changes)[https://github.com/rabbitmq/rabbitmq-server/commit/7de5a806099a5902fadba8bea28f6512ae5194eb). Mnesia: * `rabbitmqctl import 50k-classic-queues.json`: 15s * `rabbitmqctl stop_app`: 25s * `rabbitmqctl start_app`: 140s Khepri: * `rabbitmqctl import 50k-classic-queues.json`: 16s * `rabbitmqctl stop_app`:...

I've re-tested this with [the most recent changes](https://github.com/rabbitmq/rabbitmq-server/commit/7de5a806099a5902fadba8bea28f6512ae5194eb). It's significantly better, with the maxium usage of ~1.4GB: 

Indeed, if I follow the steps precisely, I also get a request to try again now. I think we can ignore this since it behaves the same way on `main`/with...

This gets even more interesting on a 3-node cluster (in my case on GKE). Import took 13m30s and the Erlangy way, 2m30s - over 5 times faster.

This gets better and better - results from a cluster with Mnesia: import: 3m49s directly from Erlang shell: 7m35s Unless I'm missing something, Khepri is significantly slower with import, while...

Yes, this was reported a long time ago and doesn't seem to be the case anymore.

Adding `--skip-binding-queues` is also useful for comparison. It skips declaring the topic bindings, so gives us 10k queue declarations and 10k direct bindings. It's also slower: For me, `perf-test -p...

``` $ rabbitmq-diagnostics memory_breakdown Reporting memory breakdown on node rabbit@kura... metadata_store: 0.4195 gb (72.47%) code: 0.0449 gb (7.75%) other_proc: 0.0325 gb (5.61%) ... ``` Nice. Thanks

I killed `beam` during the migration and RabbitMQ won't start now. Another timeout we need to ignore I guess: ``` dets: file "/home/mkuratczyk/data/rabbit@kura/mnesia/rabbit@kura/coordination/rabbit@kura/meta.dets" not properly closed, repairing ... BOOT FAILED...

I ran some quick tests and I can see `Will start up to 3 replicas for quorum queue queue X` in the (debug) logs so the intention is there. Setting...