reduce the default qi journal size

a large journal size improves performance by
- writing larger blocks to disk in one go (since in many scenarios we
  end up writing the entire journal in one go)
- reducing fsync frequency (since in many scenarios we only sync when
  rolling the journal)
- records for messages which get published, delivered and acked in the
  lifetime of a journal don't need to be written to segment files. To
  the point where we may be able to skip writing segment files
  altogether.

BUT a large size also has downsides:
- increased memory consumption
- increased amount of data loss in the event of a crash

So how do we pick a figure? Well, ultimately we may want to
dynamically adjust the size based on memory pressure, but that is a
fairly involved / risky change. Meanwhile, what would be the *lowest*
figure that still delivers all of the benefits, just somewhat less
than currently?

A single qi segment holds entries for 16k messages. We want the
journal to be able to hold at least an entire segment's worth of
publishes, delivers and acks, which would be 16k x 3 entries. That way
the aforementioned segment write reductions can happen when the queue
is small.

However, with a size of *exactly* 16k x 3, we would generally
only avoid whole segment writes when messages get published, delivered
and ack'ed straight away, which only happens when consuming in noack
mode from empty queues. So we want to add some headroom in order to
extend the benefits to a wider range of modes of queue operation.

Hence 16k x 4 is a good choice. It should allow most "near empty" fast
moving queues to avoid segment writes.

1 files changed, 1 insertions, 1 deletions

diff --git a/ebin/rabbit_app.in b/ebin/rabbit_app.in
index 16dfd196..f4d4ec3d 100644
--- a/ebin/rabbit_app.in
+++ b/ebin/rabbit_app.in
@@ -27,7 +27,7 @@
          {frame_max, 131072},
          {heartbeat, 600},
          {msg_store_file_size_limit, 16777216},
-         {queue_index_max_journal_entries, 262144},
+         {queue_index_max_journal_entries, 65536},
          {default_user, <<"guest">>},
          {default_pass, <<"guest">>},
          {default_user_tags, [administrator]},