Thomas, perfect, hours of searching Stackoverflow et al resolved in a
single mailing list thread ;--)

I will play around with various configs (per instance and multi-host per
instance) in my local devel to get an idea of no-load resource usage;
then, as you say, give some % more to avoid OOMEs in production.

Obviously per instance is a memory hungry solution, albeit highly
convenient. Placing all sites in a single instance is a possibility as
well (and the most resource "friendly"), but I would need to implement
some form of load balancing for the mid-business-day client A emergency
restart (since all sites would be affected by the restart). Of course, I
should have load balancing for the per instance solution as well to
ensure application uptime even on restart.

Hope the next version of Java addresses some of the issues with memory
leaks beyond what Tomcat 7 is already doing.  As a n00b to java land,
this one issue invokes the most doubt, clearly java roots are not in the
web per request model (i.e. request completes and everything, but
session data flushed).

Thanks for clarifying matters, Thomas, really helps to have an idea of
what you are getting into prior to working on an implementation.
-- 
--Noah

Noah Cutler
Web/Mobile Applications
New Mind Development
ad...@newminddevelopment.com
http:://newminddevelopment.com


On Tue, 2011-03-15 at 10:09 +0100, Thomas Freitag wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Noah,
> 
> On 14.03.11 um 21:27, Noah Cutler wrote:
> > So, given that a running 32-bit JVM on Linux will require at least 1GB
> > RAM, total memory usage will not be JVM footprint * num instances, but
> > rather, JVM footprint + num instances?
> 
> Actually, the 1GB are virtual memory usage, not everything is
> allocated in the physical memory. I'd say it is roughly: num instances * (JVM
> not shareable + JVM heap&perm) + JVM shareable. JVM not shareable
> could be around 200-300MB. What heap sizes do you expect?
> 
> The figures I gave for Tomcat were taken directly after
> startup. Because Tomcat starts additional threads for the connector
> thread pools these could increase (maybe 50MB instead of 5MB), and
> request processing needs some memory.
>  
> > The use case is transferring 20 client sites from LAMP stack to JVM +
> > Tomcat 7 + MySQL + a Groovy.lang web framework I developed.
> > 
> > Ideally I would separate client sites into tomcat instances, so as to
> > isolate them from each other (i.e. redeploy/restart without affecting
> > other instances), but that hinges entirely on the memory footprint.
> 
> You have to include the memory footprint of your applications into the
> calculation. If you configure small heap sizes the risk of getting
> OutOfMemoryErrors increases. If you deploy more than one application
> in your tomcat instances, average usage of heap memory, threads and
> database connections could be better.
>  
> > I have 16GB RAM available but was only planning on allocating 4-6GB RAM
> > for this project. Only a couple of the sites in question do significant
> > load (read: have been running on LAMP stack with 2GB RAM for several
> > years without issue)
> 
> I'd try a mixed approach: Run some tomcat instances with more than one
> application. Some restarts can be avoided by using hot deployments.
> The MemoryLeakPreventionListener [1] helps to check if your applications
> trigger some known memory leaks. That may fit your needs. 
> 
> I'm afraid it is very hard (or impossible) to start with an optimal
> configuration. You will have to make an educated guess (usually
> configure more ressources than necessary), monitor the resource usage, 
> and adapt the configuration to your needs.
> 
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html
> 
> Regards,
> - -- 
> Thomas Freitag
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk1/LNAACgkQGE5pHr3PKuVkTwCeJLZkrBKq9yVkEmenQUV+ItkO
> OcUAn3sznmYn/GTpbLospwQ30Kp7Ly/g
> =+pCj
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to