Hi Julian, I don't believe changing the journal sizes would have an impact in this case because the message indicates the slowness is most likely related to applying the data to the mirror databases, not transferring it from the primary.  The reason I say this is because there are two separate System Monitor alerts you could have:

  MirrorJournalLatencyTime:  time between when the last journal file was received from the primary and when it was written to the journal disk.

  MirrorDatabaseLatencyTime:  time between when the last journal file was received from the primary and when it was applied to the mirror database(s).

So in your case the backup's mirror mechanism that reads the copied journal data and then applies it to the mirror databases does not seem to be able to keep up with the rate of updates from the primary.  If it were due to slowness copying journals, you should be seeing the MirrorJournalLatencyTime alert instead.  You can read these definitions in the System Monitor documentation:

  https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon

If this continues to be an issue I recommend contacting Support (617-621-0700 or Support@InterSystems.com) and we can help to investigate this behavior.

Mack, there are multiple possibilities for why the write daemon is still on pass 31.  I recommend contacting InterSystems Support at 617-621-0700 or Support@InterSystems.com for assistance resolving this, especially if it is impacting users in any way.