If a Java application starts using more memory than expected, it usually shows up in a few predictable ways: slower response times, longer garbage collection pauses, service restarts, or deployment failures in Plesk/My App Server. In a shared hosting environment, it is especially important to separate normal JVM behaviour from a real memory problem, because Java and Tomcat naturally reserve memory for the heap, thread stacks, and internal caches.
For UK Java hosting customers running a private JVM or Apache Tomcat through My App Server, the key question is not only “is memory high?” but also “is the application reaching the memory limits available to the service, or is it just using memory efficiently?” The answer depends on the heap size, the number of threads, the application workload, and the hosting plan limits configured in the control panel.
Signs that a Java application needs more memory
A Java application may need more memory when it regularly reaches its configured limits and starts to degrade under normal traffic. The clearest signs are usually visible in logs, monitoring tools, and user experience.
Common symptoms
- Frequent OutOfMemoryError messages in the Tomcat or JVM logs.
- Application responses become slower during traffic peaks.
- Long garbage collection pauses, especially when the JVM is under load.
- Deployment or restart failures because the JVM cannot allocate enough memory.
- Tomcat starts, but the app crashes after login, report generation, or file uploads.
- Memory usage rises steadily and does not return to a stable level after normal activity.
These signs do not always mean the application simply needs “more RAM.” Sometimes the real issue is a memory leak, too many open sessions, oversized caches, or a JVM configuration that is too aggressive for the available hosting resources.
What normal memory use looks like
It is normal for a Java service to consume a meaningful amount of memory even when idle. The JVM loads classes, keeps JIT-related data, and reserves space for the heap. In Tomcat hosting, this means a service may appear to use more memory than a non-Java website, even when it is healthy.
A stable application usually shows this pattern:
- Memory rises after startup and then levels off.
- Short-term spikes happen during deployments or traffic bursts.
- Garbage collection reduces usage back to a steady range.
- The service remains responsive and does not crash.
Check the difference between heap pressure and total memory pressure
Before increasing memory, identify which part of the JVM is actually under stress. In Java hosting, “memory” can refer to several things:
- Java heap - where application objects are stored.
- Metaspace - where class metadata is kept.
- Thread stacks - memory used by active threads.
- Native memory - used by JVM internals, libraries, and direct buffers.
An application can run out of heap while still having some overall system memory available. It can also fail because of too many threads or excessive native usage. This matters in managed hosting, where the Plesk control panel and service limits may allow only a fixed amount of memory for the private JVM.
Useful log messages to look for
- java.lang.OutOfMemoryError: Java heap space - heap is too small for the workload.
- java.lang.OutOfMemoryError: Metaspace - class metadata memory is exhausted.
- java.lang.OutOfMemoryError: unable to create new native thread - too many threads or not enough memory available for thread stacks.
- GC overhead limit exceeded - the JVM is spending too much time collecting garbage and not enough time processing requests.
In a Tomcat hosting setup, these messages are often the fastest way to decide whether you need to increase memory or tune the application first.
How to review memory usage in My App Server and Plesk
If you use ITA’s Java hosting through My App Server, you can manage the private JVM and Apache Tomcat from the hosting control panel. That makes it easier to review service status, restart the app, and confirm whether the current JVM settings are suitable for the application.
Practical checks in the control panel
- Open the application/service section in Plesk and review the current Java service status.
- Check whether the service has restarted recently or stopped unexpectedly.
- Review available service usage or resource limits for the hosting account.
- Confirm the configured Java version, because version changes can affect memory behaviour.
- Check Tomcat startup parameters if they are exposed for your app.
If your application is hosted with a private JVM, the important point is that memory settings should match the available limits of the hosting service. Setting the heap too high can leave too little room for the rest of the JVM and may cause the service to fail at startup, even if the application itself is not especially large.
What to compare before changing settings
- Current heap size versus real peak usage.
- Number of active users during slow periods and traffic peaks.
- Size of uploaded files, report generation jobs, and background tasks.
- Number of threads created by the application or framework.
- Any recent code changes, library updates, or new features.
When more memory is likely the right fix
Increasing memory is reasonable when the application is healthy, but the workload has grown beyond the current JVM limits. In that case, the goal is to give the app enough room to operate without constant garbage collection or memory errors.
Typical cases where memory should be increased
- The application is used by more people than before and traffic has grown steadily.
- Reports, imports, exports, or PDF generation now require more working memory.
- A Tomcat app that was stable at launch now fails under real production data.
- Heap usage regularly reaches a high watermark before requests are complete.
- GC pauses are affecting user experience even though the application logic is correct.
In these cases, raising the heap or adjusting the JVM memory profile can be appropriate, provided the hosting plan still has headroom. On shared hosting, the better approach is usually a measured increase, not a large jump.
When more memory may not help
- A memory leak causes usage to rise continuously over time.
- The application creates too many sessions and does not clean them up.
- Caching is too aggressive and stores more data than necessary.
- The app is slow because of database queries, not memory pressure.
- Too many threads are created for the available hosting resources.
If memory keeps increasing after each restart and never stabilises, adding more memory may only delay the failure. In that case, review application code, session handling, cache policy, and background jobs first.
How to tell whether the JVM heap is too small
A small heap usually shows a repeating pattern: memory climbs quickly, garbage collection runs often, and performance dips during normal use. The application may still work, but it will feel less responsive than it should.
Questions to ask
- Does the app slow down after it has been running for some time?
- Do memory-related errors appear only during busy periods?
- Does a restart temporarily fix the problem?
- Are large requests, file uploads, or batch tasks causing the issue?
- Is the JVM spending too much time in garbage collection?
If the answer to most of these is yes, the heap may be too small for the workload. In a private JVM setup, this can often be solved by modestly increasing the heap and then retesting under normal traffic.
Good practice when increasing heap size
- Increase memory in small steps rather than making a large change at once.
- Restart the service after the change and test the same workload again.
- Monitor whether response times and GC pauses improve.
- Leave enough memory for non-heap JVM needs and the hosting environment.
How Tomcat applications use memory in hosted environments
Tomcat hosting is often a good fit for small and medium Java applications, JSP sites, servlet-based applications, and WAR deployments. However, Tomcat does not magically reduce memory needs. Your application, libraries, sessions, and caches still determine how much memory is required.
Memory-heavy features to watch
- Large in-memory HTTP sessions.
- File upload handling and temporary file buffering.
- Image or document processing.
- Reporting engines and PDF generation.
- Background schedulers that hold objects in memory.
- Framework caches and ORM session caches.
For managed Tomcat hosting through My App Server, it is usually best to keep the deployment lean: deploy only the application components you need, avoid oversized in-memory caches, and make sure session data is not larger than necessary.
Step-by-step method to decide if you need more memory
If you are not sure whether to increase memory, use a simple diagnostic process.
Step 1: Confirm the symptom
Check whether the issue is slow performance, restart failures, or a specific error message. A general slowdown may not be memory-related, so identify the exact symptom first.
Step 2: Review the logs
Look at the Tomcat and JVM logs for OutOfMemoryError, GC warnings, or repeated restart messages. Logs are often more reliable than impressions from the control panel alone.
Step 3: Compare load to memory settings
Review the current heap and any service limits in Plesk. If the application is close to the configured limit under normal traffic, you likely need a modest increase.
Step 4: Restart and test
After a restart, watch how memory behaves during a typical workload. If usage rises quickly and stays high, the heap may be too small or the app may be leaking memory.
Step 5: Separate growth from leakage
If memory grows during use but returns to a stable range after garbage collection, the application may just need a larger heap. If it keeps growing without settling, investigate the application code or cache settings.
Step 6: Adjust one thing at a time
Change heap size, thread count, or cache settings separately. This makes it easier to see what actually improved the service.
What to do before requesting a memory increase from hosting support
If you manage your Java hosting through a control panel and need help, it is useful to provide technical details. This speeds up diagnosis and helps support determine whether the problem is resource-related or application-related.
Useful information to include
- The application name and Tomcat version.
- The Java version currently in use.
- The exact error message, if any.
- When the issue started and whether anything changed recently.
- Typical traffic patterns or peak usage times.
- Whether the issue happens after deployment, login, upload, or batch processing.
Also mention whether the service runs as a private JVM under My App Server, because that helps support review the application’s memory profile in the correct hosting context.
How to reduce memory use without changing the hosting plan
Sometimes the best fix is to make the application lighter rather than larger. This is especially relevant in shared hosting, where efficient use of resources improves stability.
Practical optimisation ideas
- Reduce session data stored in memory.
- Disable or shrink large caches that are not essential.
- Review object creation in hot code paths.
- Process large files in chunks instead of loading them all at once.
- Remove unused libraries that increase class loading and memory use.
- Limit background tasks that run too frequently.
If your application uses Spring, Hibernate, or another framework, review its default cache and session settings. These defaults are often designed for flexibility, not for the tighter limits of a hosted JVM.
Memory planning tips for UK Java hosting users
For UK-based projects, the main planning factor is usually not geography but workload profile: how many users, how large the data set is, and how the app behaves during busy periods. A small internal tool may run comfortably with modest memory, while a public-facing JSP application with uploads and reports may need more headroom.
Plan for these scenarios
- Normal daily use: steady traffic with predictable memory use.
- Peak periods: payroll, month-end reporting, or business-hours spikes.
- Deployment windows: higher memory use while restarting or warming caches.
- Growth: more users, more data, or larger third-party libraries.
The safest approach is to size the JVM for expected peak usage, not for the quietest time of day. In managed hosting, a service that is comfortable at peak load tends to be much more stable overall.
FAQ
How do I know if my Java app needs more memory or has a memory leak?
If memory rises during use but returns to a stable level after garbage collection, the app may simply need more memory. If memory keeps rising over time and never settles, a memory leak is more likely.
Does a higher heap always improve Tomcat performance?
No. A larger heap can reduce garbage collection pressure, but too much heap can also be wasteful and may leave less room for the rest of the JVM. The best size is the smallest one that handles your real workload safely.
Why does my Java service use memory even when idle?
The JVM reserves memory for the heap, metadata, compiled code, and threads. This is normal behaviour in Java hosting and does not automatically mean something is wrong.
Can I run a private JVM under Plesk with different Java versions?
In My App Server, you can select from available Java and Tomcat versions, and some custom versions can be uploaded and configured manually. That flexibility helps when you need to match an application’s runtime requirements.
What should I check first if Tomcat stops after deployment?
Check the logs for memory errors, confirm the configured heap size, and review whether the new release added larger libraries, session objects, or background processing. A fresh deployment often exposes a sizing problem that was not visible before.
Is it better to increase memory or optimise the application?
Start by checking whether the current memory allocation is clearly too low. If the app is close to its limit, a small increase may help immediately. If the usage pattern looks abnormal or keeps growing, optimisation is the better long-term fix.
Conclusion
To tell whether a Java application needs more memory, look for repeatable signs: heap exhaustion, frequent garbage collection, slowdowns during normal use, and error logs that point to memory pressure. In a hosting environment with My App Server, Plesk, and a private JVM, the goal is to balance application needs with the available service limits, not to over-allocate memory by default.
For Tomcat, JSP, servlet, and WAR-based applications, the best results usually come from small, measured changes: confirm the error, review the logs, check the current JVM settings, and increase memory only when the workload clearly needs it. If memory keeps rising without stabilising, focus on leaks, sessions, cache settings, and application design before making larger resource changes.