Most Mirth slowdowns trace to four things: JVM memory pressure (check heap and GC), message storage set higher than needed on high-volume channels, an unpruned database that has grown without limit, or one slow destination blocking processing threads. Work through them in that order and re-measure under real load.
Mirth falling behind on message volume?
Senior engineers can profile and tune your environment — 15-minute response on Silver and above.
If queues are backing up in production right now, get an engineer profiling the bottleneck while you work through this guide.
Get Help With a Broken Interface →1. JVM heap and memory
If the server is doing frequent garbage collection or throwing OutOfMemoryError, throughput collapses. Check the heap setting in the Mirth service configuration (the .vmoptions file for the service/launcher) and raise the maximum heap (-Xmx) to a value appropriate for your server's RAM and message volume — without starving the OS. Pair any change with monitoring; an oversized heap can cause long GC pauses too. For the OutOfMemoryError case specifically, see the Java heap space error guide.
2. Message storage settings
Mirth's storage mode per channel has a large performance impact. Storing full content for every message (including all intermediate steps) maximizes auditability but costs the most I/O. For high-volume channels that don't need full forensic history, reduce the storage level (e.g. metadata or raw-only) to cut database load. Balance this against your compliance and reprocessing needs.
3. Pruning and database growth
An unpruned Mirth database grows without limit, and large message tables slow everything down. Configure the Data Pruner to remove or archive old messages on a schedule appropriate to your retention policy. A bloated database is one of the most common causes of gradual slowdown.
4. Database tuning
Mirth's throughput is frequently bounded by its backing database (PostgreSQL, SQL Server, etc.), not the engine. Ensure the database has adequate resources, healthy indexes, and a connection pool sized to your channel concurrency. Watch for database CPU, lock contention, and slow queries during peak load.
5. Channel and queue configuration
- A single slow destination can block processing threads and stall a channel. Identify the slowest destination and address it (downstream latency, missing index, or synchronous wait).
- Queue settings: appropriate destination queue threads and retry intervals prevent one slow endpoint from throttling everything.
- Inefficient transformers:heavy per-message work (large lookups, external calls, unbounded loops) multiplied by volume causes high CPU. Profile the busiest channel's transformer.
6. Right-size the infrastructure
If channels are tuned and the database is healthy but volume still outpaces capacity, scale: more CPU/RAM, or horizontal scaling with multiple Mirth instances behind a load balancer. Cloud-managed deployments make this easier — see managed support.
Step-by-step tuning pass
- Check JVM heap usage and GC behavior; adjust
-Xmxif memory-bound. - Review per-channel message storage; reduce on high-volume channels that don't need full content.
- Confirm the Data Pruner is running and the database isn't bloated.
- Tune the database (resources, indexes, connection pool).
- Find the slowest destination/transformer and optimize it.
- Re-measure throughput and CPU under real load.
How to prevent it
Monitor heap, queue depth, throughput, and database health continuously; keep pruning on a schedule; and review the busiest channels periodically. Most "sudden" slowdowns are gradual problems (database growth, a leaking channel) that monitoring would have flagged weeks earlier — which is the case for proactive managed support.
Want Mirth running fast and staying that way?
We profile, tune, and can manage your environment so it keeps up with volume.
Get Help With a Broken Interface →