Re: Does GC Really Matter (Is This Situation)?
Op dinsdag, 22 juni 2010 18:33 schreef "Robinson, Eric" : This is a similar question to one already being discussed in the list with the subject "Setting the Right Amount of Memory". We have 160 instances of tomcat on the same server, with most instances configured to use 64-96MB of RAM. We carefully watch the logs for OOMEs. If we see any, we increase the RAM allocation for that instance by 32MB, which is enough to make the OOMEs go away. Some people say this approach will lead to increased CPU utilization from frequent GC; however, our server runs 90% idle all day long so CPU is evidently not being driven up by much, if any. Given the circumstances, is there anything to be gained from increasing the heap size? Our software vendor wants us to increase each tomcat instance to 512MB, just as a matter of policy, but I don't see a good technical reason to do that. Am I missing something? -- Eric Robinson You can monitor the gc with jstat. jstat -gc 10s This wil show you the memory usage of a java instance with the time spent in GC. If it does 0.9 sec. of GC every sec. you are running inefficient. :-) Ronald.
Re: Does GC Really Matter (Is This Situation)?
On 22 June 2010 17:55, Robinson, Eric wrote: > Sorry, I wasn't referring specifically your comments. Over the years > I've heard the same thing a few times from different sources. It seems > to be the conventional wisdom on the subject. > > > Fifteen years ago, it was right. Memory management and GC algorithms (and processor-memory interfaces) have come on a lot since then, and advice is sometimes slow to change and adapt to new realities. - Peter
RE: Does GC Really Matter (Is This Situation)?
>> Some people say this approach will lead to increased CPU > utilization > If you're referring to what I said, note the numerous caveats I > included. Sorry, I wasn't referring specifically your comments. Over the years I've heard the same thing a few times from different sources. It seems to be the conventional wisdom on the subject. > No. Just continue to monitor the CPU and heap usage > (as it looks like you have been doing), especially if you > have an increase in overall workload. That's what I thought. Thanks. -- Eric Robinson Disclaimer - June 22, 2010 This email and any files transmitted with it are confidential and intended solely for Tomcat Users List. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of . Warning: Although has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does GC Really Matter (Is This Situation)?
> From: Robinson, Eric [mailto:eric.robin...@psmnv.com] > Subject: Does GC Really Matter (Is This Situation)? > > Some people say this approach will lead to increased CPU > utilization from frequent GC If you're referring to what I said, note the numerous caveats I included. Only if you happened to be right on the borderline of the minimum heap size would CPU usage be excessive, and all evidence indicates that none of your 160 instances are. > Given the circumstances, is there anything to be gained > from increasing the heap size? No. Just continue to monitor the CPU and heap usage (as it looks like you have been doing), especially if you have an increase in overall workload. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
