Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noah, On 3/16/2011 10:47 PM, Noah Cutler wrote: > I'll need to sort out DBCP, java singletons are nothing like php where a > singleton exists for lifetime of the request, vs. lifetime of the > application. The servlet spec includes a "request" object which (as one would expect) survives for the life of the request. HttpServletRequest (that defining class of the request objects) objects allow "attributes" to be set that are therefore accessible during the life of the request. You could store temporary resources in the request attributes if you want to be able to re-use them and discard them when the request terminates. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2D1EEACgkQ9CaO5/Lv0PD18QCgkXlLXa9ogZt32eTRcPbNqpwU n7YAoJ0dhgRbxrm9iKhrEn3ScAqQYjIG =xJlA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Chris, will likely go with mod_jk, but I did notice that Jetty folks strongly recommend mod_proxy (may be that their container works better with mod_proxy) I am not using a framework per se, one that I have written, so definitely not something like Grails with Spring + Hibernate for example. Groovy itself is memory hungry, dynamic language features such as closures, duck typing and runtime MOP come with a cost for sure. In other words, not expecting to run on 128mb as you have been attempting ;--) I'll need to sort out DBCP, java singletons are nothing like php where a singleton exists for lifetime of the request, vs. lifetime of the application. Thanks for the clarification on these issues! Noah On Wed, 2011-03-16 at 21:35 -0400, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Noah, > > On 3/16/2011 7:48 PM, Noah Cutler wrote: > > the Tomcat Groovy app will do nothing but serve up dynamic content > > (httpd will handle ssl as well), so whichever method (ajp or mod_proxy) > > peforms the best/is-most-reliable, I'll go with. > > I have a preference for mod_jk since it is more mature, has a separate > release cycle, and has more configuration options than mod_proxy_ajp. > I'm biased though since I've used mod_jk since before mod_proxy_ajp was > available. I had never considered mod_proxy_http but given the options > mod_jk has, I haven't re-considered it. > > > Love that 128mb JVM, I am very much interested in lean & mean. Coming > > from LAMP stack where memory usage is minimal for non-enterprise > > trafficked apps, the JVM seems a bit heavy handed, but power comes at a > > cost (memory) it seems. I'll need to analyze existing apache logs and > > see how many concurrent users we have on average, and then tweak Java -X > > accordingly per Tomcat instance. Assume with low traffic apps that you > > can effectively starve the JVM, giving it just enough memory to start > > (plus a small cushion), which is probably what you are doing with the > > 128mb JVM. > > If you are using a framework like JGroovy, you are adding a somewhat > thick layer on top of Java already... are you also using any other > libraries that might be either caching a lot of data or building large > object trees in memory? > > > Speaking of, what are your basic -X params to pull this off? > > Right now a simple "-Xms384M -Xmx384M". No special PermGen options, no > GC options, no nuthin'. > > > 1) low traffic app = non-pooled, connection per request > >>> this is the single tomcat instance, many virtual hosts model (low > > budget hosting) > > I would always use a connection pool, even if the pool is shallow. We > run with a mere 20 connections in production and serve hundreds of > simultaneous users (not simultaneous requests, of course). > > > 2) mid-to-high traffic app = pooled, connection per tomcat instance > >>> application has dedicated tomcat instance; connection handle is > > singleton, created on tomcat startup and shared by all users. > > I would use a pool per webapp. That allows you to size each one > appropriately for the load and one busy webapp won't starve the other > webapps out of their connections. > > > One thing I may not have mentioned is that each component will be > > running in its own virtual machine; i.e. VM1 Apache/PHP; VM2 MySQL; VM3 > > Tomcat/Groovy. > > Interesting, but not doesn't really change anything. > > > Probably will not get same performance as a bare metal setup, but the > > server has 2X 6-core 12mb cache CPU, 6X 146GB SCSI, and 16GB RAM, so I > > should be able to allocate sufficient resources to each VM and get > > decent performance -- either way, will be fun to find out ;--) > > One would hope ;) > > Good luck, > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk2BZWEACgkQ9CaO5/Lv0PCq0wCgnHkDm0aTMDNzvrj/Zazg5poi > LzoAoLEa5viGxb0FbXkX41r1NIZ3tDWS > =ES1m > -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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noah, On 3/16/2011 7:48 PM, Noah Cutler wrote: > the Tomcat Groovy app will do nothing but serve up dynamic content > (httpd will handle ssl as well), so whichever method (ajp or mod_proxy) > peforms the best/is-most-reliable, I'll go with. I have a preference for mod_jk since it is more mature, has a separate release cycle, and has more configuration options than mod_proxy_ajp. I'm biased though since I've used mod_jk since before mod_proxy_ajp was available. I had never considered mod_proxy_http but given the options mod_jk has, I haven't re-considered it. > Love that 128mb JVM, I am very much interested in lean & mean. Coming > from LAMP stack where memory usage is minimal for non-enterprise > trafficked apps, the JVM seems a bit heavy handed, but power comes at a > cost (memory) it seems. I'll need to analyze existing apache logs and > see how many concurrent users we have on average, and then tweak Java -X > accordingly per Tomcat instance. Assume with low traffic apps that you > can effectively starve the JVM, giving it just enough memory to start > (plus a small cushion), which is probably what you are doing with the > 128mb JVM. If you are using a framework like JGroovy, you are adding a somewhat thick layer on top of Java already... are you also using any other libraries that might be either caching a lot of data or building large object trees in memory? > Speaking of, what are your basic -X params to pull this off? Right now a simple "-Xms384M -Xmx384M". No special PermGen options, no GC options, no nuthin'. > 1) low traffic app = non-pooled, connection per request >>> this is the single tomcat instance, many virtual hosts model (low > budget hosting) I would always use a connection pool, even if the pool is shallow. We run with a mere 20 connections in production and serve hundreds of simultaneous users (not simultaneous requests, of course). > 2) mid-to-high traffic app = pooled, connection per tomcat instance >>> application has dedicated tomcat instance; connection handle is > singleton, created on tomcat startup and shared by all users. I would use a pool per webapp. That allows you to size each one appropriately for the load and one busy webapp won't starve the other webapps out of their connections. > One thing I may not have mentioned is that each component will be > running in its own virtual machine; i.e. VM1 Apache/PHP; VM2 MySQL; VM3 > Tomcat/Groovy. Interesting, but not doesn't really change anything. > Probably will not get same performance as a bare metal setup, but the > server has 2X 6-core 12mb cache CPU, 6X 146GB SCSI, and 16GB RAM, so I > should be able to allocate sufficient resources to each VM and get > decent performance -- either way, will be fun to find out ;--) One would hope ;) Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2BZWEACgkQ9CaO5/Lv0PCq0wCgnHkDm0aTMDNzvrj/Zazg5poi LzoAoLEa5viGxb0FbXkX41r1NIZ3tDWS =ES1m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Chris, great feedback. the Tomcat Groovy app will do nothing but serve up dynamic content (httpd will handle ssl as well), so whichever method (ajp or mod_proxy) peforms the best/is-most-reliable, I'll go with. Love that 128mb JVM, I am very much interested in lean & mean. Coming from LAMP stack where memory usage is minimal for non-enterprise trafficked apps, the JVM seems a bit heavy handed, but power comes at a cost (memory) it seems. I'll need to analyze existing apache logs and see how many concurrent users we have on average, and then tweak Java -X accordingly per Tomcat instance. Assume with low traffic apps that you can effectively starve the JVM, giving it just enough memory to start (plus a small cushion), which is probably what you are doing with the 128mb JVM. Speaking of, what are your basic -X params to pull this off? Re: DBCP and per user per request connection handle, yes, not well thought out, am putting the pieces together component-wise; most in the know suggest connection pooling vs. per request connections. Correct me if I am wrong here, but as I see it, there are 2 basic approaches for database connectivity on the JVM: 1) low traffic app = non-pooled, connection per request >> this is the single tomcat instance, many virtual hosts model (low budget hosting) 2) mid-to-high traffic app = pooled, connection per tomcat instance >> application has dedicated tomcat instance; connection handle is singleton, created on tomcat startup and shared by all users. One thing I may not have mentioned is that each component will be running in its own virtual machine; i.e. VM1 Apache/PHP; VM2 MySQL; VM3 Tomcat/Groovy. Probably will not get same performance as a bare metal setup, but the server has 2X 6-core 12mb cache CPU, 6X 146GB SCSI, and 16GB RAM, so I should be able to allocate sufficient resources to each VM and get decent performance -- either way, will be fun to find out ;--) Noah On Wed, 2011-03-16 at 18:26 -0400, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Noah, > > On 3/15/2011 7:02 PM, Noah Cutler wrote: > > However, some of the LAMP stack apps will have legacy/archived > > functionality that I have zero interest/time in porting over to > > JVM/Groovy framework. So, the plan is to mod_rewrite archived requests > > to php, along with static files (css,jss,html,etc.), and use Tomcat to > > serve up non-legacy dynamic content, connecting via AJP or mod_proxy. > > Sounds reasonable: you you've already got Apache httpd in the mix, so > multiplexing between multiple backend Tomcats isn't a big deal, then. > FYI mod_proxy will also do AJP if you want. The protocol is slightly > more optimized than HTTP proxying, but does not (directly) include any > options for encryption and is a tiny bit harder to debug when problems > arise. > > > Amazed that you have been able to tweak JVM memory usage down to as > > little as 128mb, incredible. > > We have a very lean and mean webapp: small transactions and very little > stored in the session. We only have to increase the heap size as the > number of concurrent users grows. We've had to do this twice in > production, and the first time it was growing from a 64MiB heap up to > 192MiB (just for good measure). Our last release had a huge problem with > it that was bringing way too many rows back from the db and caching them > in the user's session and we've had to temporarily grow up to 385MiB to > keep that under control before a fix can be put in place. > > We use Struts 1 as our app framework and use our own hand-written JDBC > queries to fetch data from our RDBMS, so there's not a whole lot of junk > laying around. > > > The OOME issue is a real one given my lack > > of experience in Java -- have @5 months Groovy under my belt and am > > enjoying it far too much to return to php -- so "important" client sites > > will have their own dedicated Tomcat instance; the rest, I'll virtual > > host in a single instance. > > Sounds like a plan. > > If you have any more questions, definitely come back to the list. > > > Am interested in Tomcat 7's new DBCP model as well. Coupled with Groovy > > per request singleton (unlike per instance/application lifetime), I > > should be able create a db connection handle on request start and > > thereafter have all queries in the request run against this cached > > connection (could also do a true singleton, the most efficient, but as I > > understand, singletons are specific to the entire instance, and > > therefore will not work for a virtual hosts setup). > > I don't think that's what you want to do. Typically, a connection pool > will have a fixed number of connections for a (somewhat) unlimited > number of users. If you assign a db connection to each user, you are > tying-up resources on the db server for a user who may disappear and > never explicitly log out, freezing that connection until some timeout > occurs. Worse, you have to have potentially thousands of co
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noah, On 3/15/2011 7:02 PM, Noah Cutler wrote: > However, some of the LAMP stack apps will have legacy/archived > functionality that I have zero interest/time in porting over to > JVM/Groovy framework. So, the plan is to mod_rewrite archived requests > to php, along with static files (css,jss,html,etc.), and use Tomcat to > serve up non-legacy dynamic content, connecting via AJP or mod_proxy. Sounds reasonable: you you've already got Apache httpd in the mix, so multiplexing between multiple backend Tomcats isn't a big deal, then. FYI mod_proxy will also do AJP if you want. The protocol is slightly more optimized than HTTP proxying, but does not (directly) include any options for encryption and is a tiny bit harder to debug when problems arise. > Amazed that you have been able to tweak JVM memory usage down to as > little as 128mb, incredible. We have a very lean and mean webapp: small transactions and very little stored in the session. We only have to increase the heap size as the number of concurrent users grows. We've had to do this twice in production, and the first time it was growing from a 64MiB heap up to 192MiB (just for good measure). Our last release had a huge problem with it that was bringing way too many rows back from the db and caching them in the user's session and we've had to temporarily grow up to 385MiB to keep that under control before a fix can be put in place. We use Struts 1 as our app framework and use our own hand-written JDBC queries to fetch data from our RDBMS, so there's not a whole lot of junk laying around. > The OOME issue is a real one given my lack > of experience in Java -- have @5 months Groovy under my belt and am > enjoying it far too much to return to php -- so "important" client sites > will have their own dedicated Tomcat instance; the rest, I'll virtual > host in a single instance. Sounds like a plan. If you have any more questions, definitely come back to the list. > Am interested in Tomcat 7's new DBCP model as well. Coupled with Groovy > per request singleton (unlike per instance/application lifetime), I > should be able create a db connection handle on request start and > thereafter have all queries in the request run against this cached > connection (could also do a true singleton, the most efficient, but as I > understand, singletons are specific to the entire instance, and > therefore will not work for a virtual hosts setup). I don't think that's what you want to do. Typically, a connection pool will have a fixed number of connections for a (somewhat) unlimited number of users. If you assign a db connection to each user, you are tying-up resources on the db server for a user who may disappear and never explicitly log out, freezing that connection until some timeout occurs. Worse, you have to have potentially thousands of connections to the back-end which may kill your db: all of those connections require a non-trivial amount of memory to manage. It's usually sufficient to grab a connection from the pool, use it, then put it back. If you have a use case where some other strategy makes sense, I'd be glad to hear it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2BORUACgkQ9CaO5/Lv0PAEhQCfZkOUFQ7r80Jp/7a2q1RJeeGg sw8An2vtc0DnZ4oj56JN+xEv39aaVi78 =bKzA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Thomas, yes, I have seen a few sample mod_jk configs, does not look difficult to implement. Load balanced, per instance and/or virtual host setup with new DBCP, what more could one ask for ;--) I am really looking forward to generating dynamic content with Groovy on Tomcat, quite lightweight compared to say, Grails, which requires bare minimum 512mb to run poorly, and 1024mb to run well, ouch. Thanks for the tips... Noah On Wed, 2011-03-16 at 06:25 +0100, Thomas Freitag wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Noah, > > On 03/15/2011 07:05 PM, Noah Cutler wrote: > > 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. > > That could be done with a combination of Apache httpd and mod_jk (my > preffered way), mod_proxy_ajp or mod_proxy_http. For mod_jk there is a > very good documented, almost ready to start configuration in the source > download. > > Regards, > - -- > Thomas Freitag > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk2ASbsACgkQGE5pHr3PKuXf3ACeL35NqbxT912UJmQcsLsRqeJz > 8pQAn3sEYamqbBAceNpejbX0cJ/olWYR > =4lmj > -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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Noah, On 03/15/2011 07:05 PM, Noah Cutler wrote: > 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. That could be done with a combination of Apache httpd and mod_jk (my preffered way), mod_proxy_ajp or mod_proxy_http. For mod_jk there is a very good documented, almost ready to start configuration in the source download. Regards, - -- Thomas Freitag -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2ASbsACgkQGE5pHr3PKuXf3ACeL35NqbxT912UJmQcsLsRqeJz 8pQAn3sEYamqbBAceNpejbX0cJ/olWYR =4lmj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Chris, thanks for the excellent feedback; thus far this list exceeds Stackoverflow by orders of magnitude ;--) Re: ease of implementation, yes, a single instance with multiple virtual hosts is the way to go (similar setup to apache virtual hosts). However, some of the LAMP stack apps will have legacy/archived functionality that I have zero interest/time in porting over to JVM/Groovy framework. So, the plan is to mod_rewrite archived requests to php, along with static files (css,jss,html,etc.), and use Tomcat to serve up non-legacy dynamic content, connecting via AJP or mod_proxy. Amazed that you have been able to tweak JVM memory usage down to as little as 128mb, incredible. The OOME issue is a real one given my lack of experience in Java -- have @5 months Groovy under my belt and am enjoying it far too much to return to php -- so "important" client sites will have their own dedicated Tomcat instance; the rest, I'll virtual host in a single instance. Am interested in Tomcat 7's new DBCP model as well. Coupled with Groovy per request singleton (unlike per instance/application lifetime), I should be able create a db connection handle on request start and thereafter have all queries in the request run against this cached connection (could also do a true singleton, the most efficient, but as I understand, singletons are specific to the entire instance, and therefore will not work for a virtual hosts setup). Lots to learn clearly, but am loving the potential here, sky is the limit performance-wise... -- --Noah Noah Cutler Web/Mobile Applications New Mind Development ad...@newminddevelopment.com http:://newminddevelopment.com On Tue, 2011-03-15 at 16:26 -0400, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Noah, > > On 3/15/2011 2:05 PM, Noah Cutler wrote: > > 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. > > Something else to consider is that your configuration becomes more > complicated when you decide to go to more than 1 JVM: you'll have to use > a fronting web server to determine which backend JVM to contact. > > If you have a single JVM, you can use it directly as your web server > with no other moving parts. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk1/y2IACgkQ9CaO5/Lv0PD4MQCgkWFA858UtCfSUmR+vlmnKI1l > kwAAniGvFqVvLI4jfTJKzPEqXfyh4y05 > =zT2G > -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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noah, On 3/15/2011 2:05 PM, Noah Cutler wrote: > 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. Something else to consider is that your configuration becomes more complicated when you decide to go to more than 1 JVM: you'll have to use a fronting web server to determine which backend JVM to contact. If you have a single JVM, you can use it directly as your web server with no other moving parts. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1/y2IACgkQ9CaO5/Lv0PD4MQCgkWFA858UtCfSUmR+vlmnKI1l kwAAniGvFqVvLI4jfTJKzPEqXfyh4y05 =zT2G -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noah, On 3/15/2011 3:27 AM, 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? Not necessarily. We also run under 32-bit Linux (happens to be Tomcat 6.0.32 but it's not that different) and have JVMs that run under 128MiB of RAM when configured in a certain way. Obviously, your -Xmx settings have a lot to do with how much memory will be used, as well as the number of threads that are managed by the JVM, etc. > 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. Ideally, you should be able to deploy/redeploy individual webapps without interfering with each other. If you have specific concerns, let us know and we might be able to comment. Running under a SecurityManager can certainly help protect webapps from each other -- things like prohibiting System.exit, etc. > 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) We run each of our webapps in a separate JVM/Tomcat process to isolate them from resource conflicts -- we don't want one app to OOME and bring down the others, for instance. If you have some webapps that are particularly memory heavy or you are worried about, you can separate them and run the others together. Certainly running everything together in a single VM will be more memory efficient but they might interfere in various ways. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1/yWQACgkQ9CaO5/Lv0PBI0gCgq+wYJic2sWUoQsmM8aB9qHap QL8AoLwI0cphsgZDRR+T5cr6pcpGxDfz =L/Ot -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
Thomas, excellent, informative. 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? 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. 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) -- --Noah Noah Cutler Web/Mobile Applications New Mind Development ad...@newminddevelopment.com http:://newminddevelopment.com On Tue, 2011-03-15 at 07:43 +0100, Thomas Freitag wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Noah, > > On 03/15/2011 06:25 AM, Noah Cutler wrote: > > can find nothing on the net re: this apparently basic question. > > > > Given a simple hello world "app", what is the @memory footprint per > > instance in Tomcat 7? > > > > Just trying to assess options visa vi single instance + multiple virtual > > hosts vs. multiple instance single host (preferred option as each client > > app is isolated from the other). > > There is a simple answer from the Java Heap point of view, a stock > Apache Tomcat 7.0.11 (running in Oracle JVM 1.6.0_24) around 3.5MB in > Heap, 11MB in Permanent Generation after startup (see garbage collection > log): > > Heap after GC invocations=5 (full 2): > PSYoungGen total 18752K, used 0K [0x9ea5, 0x9ff3, 0xb38f) > eden space 16128K, 0% used [0x9ea5,0x9ea5,0x9fa1) > from space 2624K, 0% used [0x9fa1,0x9fa1,0x9fca) > to space 2624K, 0% used [0x9fca,0x9fca,0x9ff3) > PSOldGentotal 42880K, used 3417K [0x74cf, 0x776d, > 0x9ea5) > object space 42880K, 7% used [0x74cf,0x75046520,0x776d) > PSPermGen total 18176K, used 10916K [0x70cf, 0x71eb, > 0x74cf) > object space 18176K, 60% used [0x70cf,0x71799068,0x71eb) > > - From the system (32bit Linux in my test case) point of view, my test > with pmap gave me a total of 1191428K (~ 1.1GB). This includes shared > libraries, Heap, Perm, code cache and other native memory (stacks, > buffers etc), thus some of this can be used by other JVM instances... > > To cut it short: Tomcats memory footprint is very small, that shouldn't > be a problem for you. The JVM memory footprint depends on JVM version, > operating system and might be a problem if you run many JVM instances. > Test it in your system... > > Regards, > - -- > Thomas Freitag > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk1/CqkACgkQGE5pHr3PKuWldQCfag8Uy0K445QX6uMhyJLjRtzL > Et8AnjSva8LzilB3gp7Zobc1TdRr0J/S > =/Zul > -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
Re: Tomcat 7 Per Instance Memory Footprint in Hello World App.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Noah, On 03/15/2011 06:25 AM, Noah Cutler wrote: > can find nothing on the net re: this apparently basic question. > > Given a simple hello world "app", what is the @memory footprint per > instance in Tomcat 7? > > Just trying to assess options visa vi single instance + multiple virtual > hosts vs. multiple instance single host (preferred option as each client > app is isolated from the other). There is a simple answer from the Java Heap point of view, a stock Apache Tomcat 7.0.11 (running in Oracle JVM 1.6.0_24) around 3.5MB in Heap, 11MB in Permanent Generation after startup (see garbage collection log): Heap after GC invocations=5 (full 2): PSYoungGen total 18752K, used 0K [0x9ea5, 0x9ff3, 0xb38f) eden space 16128K, 0% used [0x9ea5,0x9ea5,0x9fa1) from space 2624K, 0% used [0x9fa1,0x9fa1,0x9fca) to space 2624K, 0% used [0x9fca,0x9fca,0x9ff3) PSOldGentotal 42880K, used 3417K [0x74cf, 0x776d, 0x9ea5) object space 42880K, 7% used [0x74cf,0x75046520,0x776d) PSPermGen total 18176K, used 10916K [0x70cf, 0x71eb, 0x74cf) object space 18176K, 60% used [0x70cf,0x71799068,0x71eb) - From the system (32bit Linux in my test case) point of view, my test with pmap gave me a total of 1191428K (~ 1.1GB). This includes shared libraries, Heap, Perm, code cache and other native memory (stacks, buffers etc), thus some of this can be used by other JVM instances... To cut it short: Tomcats memory footprint is very small, that shouldn't be a problem for you. The JVM memory footprint depends on JVM version, operating system and might be a problem if you run many JVM instances. Test it in your system... Regards, - -- Thomas Freitag -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1/CqkACgkQGE5pHr3PKuWldQCfag8Uy0K445QX6uMhyJLjRtzL Et8AnjSva8LzilB3gp7Zobc1TdRr0J/S =/Zul -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 Per Instance Memory Footprint in Hello World App.
Hi, can find nothing on the net re: this apparently basic question. Given a simple hello world "app", what is the @memory footprint per instance in Tomcat 7? Just trying to assess options visa vi single instance + multiple virtual hosts vs. multiple instance single host (preferred option as each client app is isolated from the other). TIA and looking forward to using Tomcat 7! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
