When you host a Tomcat application, the most important limits are usually not the same as for a static website. A Java app needs enough memory for the JVM, enough CPU time to handle requests, enough disk space for the application files and logs, and enough open resources to keep sessions, threads, and connections stable. If one of these limits is too low, the app may still start, but it can become slow, fail under load, or restart unexpectedly.
In a managed hosting environment with Plesk and a private Tomcat/JVM setup, the best approach is to size resources around the real behavior of the application rather than only around file size. For small and medium Tomcat deployments, this usually means checking memory first, then CPU, then disk and process limits, and finally request-related limits such as threads and connection pools.
Why resource limits matter for Tomcat hosting
Tomcat is a Java-based application server, so every application runs inside the Java Virtual Machine. That means the app does not only need space for its code and web files, but also for:
- the JVM itself,
- class loading and bytecode,
- heap memory for objects and sessions,
- thread stacks,
- temporary files and cached data,
- logs generated by the application and Tomcat.
On shared hosting or managed hosting with My App Server, resource limits help keep each service stable and predictable. They also protect other services on the same account from one application using too much memory or too many processes.
The most important Tomcat resource limits
1. Memory limit for the JVM
Memory is the first limit to check for any Tomcat application. A Java app can run out of heap memory even if the server still has free disk space and CPU. If the heap is too small, you may see slow performance, frequent garbage collection, or errors such as OutOfMemoryError.
When planning memory, think about three parts:
- JVM heap – where most Java objects live.
- Metaspace / class metadata – needed for loaded classes and libraries.
- Native overhead – threads, buffers, SSL, and other JVM internals.
For a small Tomcat site, a modest heap may be enough. For a multi-module application, larger session storage, or heavier libraries, the JVM can need much more. In practice, it is safer to leave headroom instead of assigning nearly all available memory to the heap.
What to watch for:
- slow response times during traffic spikes,
- frequent garbage collection pauses,
- application restarts,
- memory-related errors in Tomcat logs.
2. CPU limit and processing capacity
CPU matters when requests require parsing, validation, rendering, encryption, database calls, or background tasks. A Tomcat service can be memory-stable but still slow if CPU is saturated.
In hosting, CPU limits are often expressed as a fair-use quota, a process priority, or a maximum share of available resources. For a Java app, CPU pressure often shows up as:
- slow page generation,
- delayed API responses,
- long login times,
- timeouts during busy periods.
CPU-heavy applications may also trigger more garbage collection activity, which increases load further. If your Tomcat app uses background jobs, report generation, PDF creation, image processing, or frequent XML/JSON transformation, CPU should be reviewed early.
3. Disk space for the application, logs, and temporary files
Disk usage is often underestimated in Tomcat hosting. The deployed WAR file may be small, but the real footprint includes:
- expanded application files,
- Tomcat work directories,
- temporary uploads,
- application logs,
- rotated log history,
- cache files and exports.
Even a stable application can fill disk space over time if logs grow without rotation or if temporary files are not cleaned up. When disk becomes full, the app may stop writing logs, fail to upload files, or break session persistence and deployment operations.
For hosted Tomcat, it is good practice to monitor both the application directory and the service working directories in Plesk or in your file manager. Keep some free space for updates, archive files, and diagnostic logs.
4. Number of processes and service instances
In a managed hosting setup, the number of allowed processes can be just as important as memory. Tomcat is usually one main JVM process, but it may create helper threads and occasionally spawn additional tasks depending on the application.
If the hosting account has process limits that are too low, you may see:
- service start failures,
- deployment issues,
- thread creation errors,
- timeouts during imports or scheduled jobs.
This is especially important if you use a private JVM inside a shared hosting account. The service should have enough process allowance to run Tomcat cleanly without hitting account-level restrictions.
5. Thread count and request concurrency
Tomcat handles many connections using worker threads. More threads can improve concurrency, but too many threads can increase memory use and context switching. Too few threads can make the app queue requests and feel slow under load.
Thread-related limits matter most when the application receives many simultaneous users, AJAX calls, or API requests. Each thread also uses stack memory, so increasing thread pool size can raise the total memory footprint of the JVM.
A balanced thread pool is usually better than a very large one. If response time becomes inconsistent under load, check whether the thread pool is waiting on database calls, external APIs, or slow backend services.
6. Database connections and external service usage
Many Tomcat apps spend more time waiting on databases than on Java code. Connection pool size, database timeouts, and external API limits can become the real bottleneck even when Tomcat itself has enough memory and CPU.
Watch for:
- connection pool exhaustion,
- slow SQL queries,
- too many open connections,
- timeouts to third-party services.
If your application holds connections for too long or creates too many at once, you may need to adjust the app configuration rather than only increasing hosting resources.
7. Session storage and cache growth
Tomcat applications that use many user sessions can consume much more memory than expected. Sessions store login state, shopping cart data, preferences, and temporary objects. If sessions are large or remain active for a long time, memory usage grows quickly.
Application caches can also increase resource usage. Caching helps performance, but it must be sized carefully. A cache that is too large can create memory pressure, while a cache that is too small may not help much.
How to estimate the right limits for a Tomcat application
The safest way to size a Tomcat hosting environment is to start from real usage patterns. If you are moving an app into My App Server, review the current usage before deciding on limits.
Step 1: Check the current memory footprint
Look at how much memory the application uses after startup and during normal activity. Compare idle usage with peak usage. If the app is already close to the limit at idle, it will likely fail under real traffic.
Useful signals include:
- JVM heap usage after warm-up,
- garbage collection frequency,
- metaspace growth,
- log entries about memory pressure.
Step 2: Review peak traffic and concurrency
Count how many users or requests the application handles at the same time. A low-traffic internal app may need only modest resources, while a public-facing site with login, search, and file upload features may require more.
Pay attention to:
- simultaneous sessions,
- request bursts after publishing or importing data,
- scheduled jobs that run during business hours,
- background processing and queue workers.
Step 3: Separate application code from supporting services
Tomcat itself is only part of the picture. If your application also uses MySQL, external APIs, email sending, storage uploads, or image manipulation, those activities increase total resource needs. A small codebase can still create a heavy workload if it depends on many external services.
Step 4: Check disk growth over time
Some apps look small on day one but grow with logs, exports, temporary uploads, and backups. Review how much data is created per week or per month. If the app generates reports or uploads files, make sure disk space is sized for future growth.
Step 5: Test a realistic workload
If possible, test the app with sample data and real user actions. Watch memory, CPU, response time, and logs during the test. A short load test often reveals whether the current resource limits are safe or too tight.
Typical signs that resource limits are too low
Many Tomcat issues first appear as general slowness, not as direct error messages. Common symptoms include:
- Tomcat starts but becomes slow after some time,
- pages load normally at first and then time out,
- the application restarts without an obvious reason,
- uploads fail or temporary files disappear,
- log files show memory errors or thread exhaustion,
- background jobs stop completing.
If you see these patterns, do not increase one limit blindly. Check whether memory, CPU, and thread settings match the actual workload. In many cases, a configuration adjustment in the application is needed alongside a hosting limit change.
Tomcat settings that affect resource usage
JVM heap size
The heap controls how much memory Java can use for objects. If you set it too low, the app may spend too much time garbage collecting. If you set it too high, the JVM may leave too little memory for native overhead and the system can become unstable.
Garbage collection behavior
Garbage collection is normal in Java, but excessive GC is a sign that the application is under memory pressure or that objects are being created too quickly. Monitoring GC helps identify whether the memory limit is realistic.
Tomcat thread pool configuration
The connector thread pool affects how many requests Tomcat can process at the same time. Larger pools can help with concurrency, but they also increase memory usage. The correct setting depends on the app’s request pattern and backend speed.
Session timeout and application caching
Long session timeouts and aggressive caches make the application feel efficient, but they can also increase memory usage. Review these settings if the app has many users or large objects in session state.
Practical hosting recommendations in Plesk and My App Server
In a Plesk-based hosting environment with My App Server, the goal is to keep the Tomcat service predictable and easy to manage. For small and medium Java applications, the most useful practices are:
- choose the Java version that matches the application requirements,
- keep the JVM separate from other services in the account,
- monitor service status regularly,
- review logs after each deployment,
- adjust heap and thread settings gradually,
- avoid oversized caches unless they are clearly needed,
- clean temporary files and rotated logs.
If you use a WAR deployment, remember that the deployed package size is not the same as the runtime footprint. A small WAR can still require a large JVM heap if it loads many libraries or stores data in memory.
When to increase memory, and when to optimize the application first
Increase memory when the application is genuinely outgrowing its current heap or when normal usage causes frequent GC and memory errors. Optimize the application first when:
- the app keeps too much data in session,
- an upload or import job leaks memory,
- the app creates unnecessary objects in loops,
- logs show repeated resource spikes during one specific action,
- slow database queries are holding requests open too long.
In many Tomcat deployments, better code or cleaner configuration solves more than a larger limit. The best result usually comes from right-sizing both the hosting resources and the application settings.
Recommended checklist before launching a Tomcat app
- Confirm the JVM heap size is appropriate for the expected traffic.
- Check that disk space allows for logs, uploads, and temporary files.
- Review Tomcat thread settings and expected concurrency.
- Verify database connection pool settings.
- Make sure the Java version is compatible with the application.
- Test startup, deployment, login, and file upload flows.
- Check service control options in Plesk or the hosting panel.
- Review logs after the first day of real usage.
FAQ
What is the single most important limit for Tomcat?
For most Tomcat applications, memory is the most important limit because the JVM needs enough heap and native memory to run reliably. If memory is too low, the app may fail even if CPU and disk are available.
Can a Tomcat app run on low resources if traffic is small?
Yes, a small app with low traffic can often run comfortably with modest limits. The key is to leave enough memory for the JVM and enough disk for logs and temporary files. Even low-traffic apps can fail if they have memory leaks or large sessions.
Why does Tomcat slow down even when CPU is not fully used?
This often happens when the app is waiting on database connections, external APIs, or garbage collection. It can also happen when the thread pool is too small or when memory pressure causes pauses.
How do I know whether I need more heap or better code?
If memory usage climbs steadily and the application throws memory-related errors, more heap may help. If a specific page, import, or report causes spikes, the code or the configuration may need optimization first. Logs and real usage data are the best guide.
Does the WAR file size tell me how much memory I need?
No. WAR size is only a rough indicator. Runtime memory depends on loaded classes, sessions, caching, threads, and how the application behaves after startup.
What should I monitor after deploying Tomcat in a hosted environment?
Monitor memory usage, garbage collection, CPU load, disk space, log growth, response times, and service uptime. These metrics show whether the current resource limits are suitable.
Conclusion
For a Tomcat application, the resource limits that matter most are memory, CPU, disk space, process allowance, thread capacity, and database connection usage. In a managed hosting setup with Plesk and My App Server, these limits should be sized around the real workload of the Java application, not just the file size or the number of pages.
If you keep an eye on JVM memory first, then request concurrency, logs, and disk growth, you can usually avoid the most common Tomcat hosting problems. For small and medium Java, JSP, and servlet applications, that approach gives you a stable private JVM environment with practical control and predictable service behavior.