Mirth Connect PermGen Out of Memory Error: Causes, Fix, and Prevention

A Mirth Connect PermGen out of memory error shows up in the server log as java.lang.OutOfMemoryError: PermGen space, almost always after several channel redeploys or long uptime without a restart. It's a different failure from a heap space error — this one is about class metadata, not message data.

Below is the exact cause, the config change that fixes it, and how to stop it recurring. If you'd rather have someone confirm the fix on your instance directly, our free Mirth Health Check reviews your JVM settings and deploy history in one pass, part of the broader Mirth Connect support work we do for US healthcare teams.

PermGen (Permanent Generation) is the JVM memory region that stores loaded class metadata, separate from the heap that holds message and object data. On Java 7 and earlier, Mirth Connect's habit of reloading classes on every channel deploy, extension install, or driver update fills this fixed-size region faster than most default JVM settings account for. Unlike heap memory, PermGen classes referenced by lingering classloaders are never garbage collected, so the pool only grows until the server crashes with an out of memory error.

Frequent Channel Redeploys Without a Restart

Every time a channel is deployed or undeployed, Mirth's classloader reloads dependent classes but the old class definitions often aren't fully released. Dozens of redeploys in a single server session can exhaust a default-sized PermGen region within hours.

Classloader Leaks From Custom JavaScript or Java Code

Custom transformers or filters that reference static classes, threads, or third-party libraries can pin classloaders in memory. Each redeploy then creates a new classloader instance alongside the leaked one instead of replacing it.

Running on Java 7 or Earlier Without Metaspace

Java 8 replaced PermGen with Metaspace, which resizes dynamically by default. Instances still running on Java 6 or 7 inherit a fixed-size PermGen that must be tuned manually, and most default installs never touch that setting.

Third-Party JDBC Drivers or Extensions Reloaded Repeatedly

Database drivers and commercial extensions loaded fresh on every deploy add to the same finite space. Environments running several database writer channels alongside custom extensions hit the ceiling sooner than simpler setups.

The right fix depends on which Java version the Mirth server is running, since PermGen and Metaspace are configured differently. Increasing the memory ceiling on an older JVM buys time and stops the immediate crash, while moving to Java 8 or later removes the fixed limit entirely by switching to dynamically resizing Metaspace. Both changes live in the Mirth service wrapper configuration rather than inside the Administrator client, so they take a service restart, not just a channel redeploy, to apply.

Increase MaxPermSize on Java 7 and Earlier

Edit conf/wrapper.conf and add or raise the PermGen flag:

wrapper.java.additional.<n>=-XX:MaxPermSize=256m

Restart the Mirth service for the change to take effect, and confirm the new limit with jstat -gc while the server is under load.

Migrate to Java 8 or Later and Use Metaspace

Upgrading the JVM removes PermGen entirely in favor of Metaspace, which grows as needed unless you cap it. Set -XX:MaxMetaspaceSizeonly if you've seen runaway growth; otherwise leave it unbounded and monitor.

Restart the Mirth Service Instead of Redeploying Repeatedly

If the server is already throwing the error, a full service restart clears the leaked classloaders immediately. Redeploying the offending channel again without restarting first will not free the memory already consumed.

Remove Unused Extensions and Database Drivers

Uninstall commercial extensions and JDBC drivers that aren't actively used by any deployed channel. Each one loaded at startup or on deploy claims PermGen or Metaspace space that a leaner install wouldn't need.

Fixing the immediate error doesn't stop it coming back if the underlying deploy pattern hasn't changed, since a raised memory ceiling just delays the same leak. Prevention here is mostly about visibility — knowing PermGen or Metaspace usage is climbing before the server actually crashes — combined with reducing how often classes get reloaded in production. That means monitoring tools, a sensible restart schedule, and periodically checking custom channel code for the classloader leaks that cause most repeat incidents on the same instance.

Monitor JVM Memory With VisualVM or JConsole

Attach VisualVM to the Mirth server process and watch the PermGen or Metaspace pool during a normal deploy cycle. A pool that climbs and never drops after several deploys confirms a classloader leak rather than a one-off spike.

Schedule Planned Restarts During Low-Traffic Windows

A weekly or nightly restart during a low-volume window clears accumulated classloader references before they become a crash. This is a workaround, not a fix, but it's a reasonable stopgap while you diagnose custom code.

Audit Channels for Memory-Heavy Custom Code

Review JavaScript transformers and filters for static references, unclosed threads, or cached objects that persist across deploys. These are the most common source of leaks that a JVM upgrade alone won't resolve. For the language-level patterns behind both engines, see our Mirth Connect Groovy vs JavaScript transformers guide.

Keep Mirth and Java Versions Current

Newer Mirth releases and current LTS Java versions handle classloading more efficiently than older combinations. If you're still on Java 7 for compatibility reasons, our Mirth Connect upgrade guide covers what changes before you move.

If you've raised MaxPermSize or moved to Metaspace and the error still recurs, the underlying cause is usually a classloader leak in custom transformer code that won't show up until you profile a live deploy cycle. Our free Mirth Connect health check covers JVM memory settings and deploy history as part of the standard diagnostic.

Book a Free Health Check →

Prefer to send the exact error first? Send us the log and we'll tell you what's wrong, or check pricing for ongoing support plans.