tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Solofnenko <A.Solofne...@mdl.com>
Subject Re: Tomcat with 8 GB memory
Date Sat, 28 Jul 2007 07:04:15 GMT
The 32 versus 64 bit was discussed on a different branch of this thread.

- Alexey.

Ron Wheeler wrote:
> If you read the article that I cited from Microsoft, you will find a 
> discussion about 32 bit and 64 bit performance that includes a lot of 
> these discussions including why a 64 bit Java Virtual Machine is 
> better than a 32 bit version of Java.
>
> A 32 bit OS will limit you to a 2 GB process space which has to 
> include all your code and your heaps.
> If you are running Tomcat, you just run out of places to put user 
> requests and eventually you start to fail to respond to requests.
>
> If you only need to serve a few users, it does not really matter what 
> you pick from today's hardware and OS choices.
> If you need to support thousands of users making steady streams of 
> requests, you want a 64 bit application starting with the hardware and 
> going up through the OS to the JVM and the servlet engine.
>
> If you want to actually have Tomcat with 8GB of memory, you need 64 
> bits otherwise you are getting Tomcat with 2 Gb memory with 6 GB left 
> over.
>
> Read the article. It is a nice change from folklore.
>
> You might also want to find some textbooks on basic Computer Science 
> to avoid being misled by foolishness.
>
> Ron
>
>
>
> Joe Nathan wrote:
>> Alexey Solofnenko-2 wrote:
>>  
>>> No, each of two 4GB processes will have only a half of the objects 
>>> under the same load. And I heard that GC does not scale linear with 
>>> heap size. And this is without multi-threading performance 
>>> considerations.  As usual, your mileage may vary and only tests can 
>>> tell for sure.
>>>
>>>     
>>
>> It's not easy to measure gc time, especially if it is based on 
>> generational
>> gc algorithm which does NOT do gc for all objects. In addition, a 
>> single gc does not remove all obsolate objects. They are often 
>> removed at the second or third time gc.
>> When you test, monitor IO activities as well, potentially stemming 
>> from virtual memory paging activities. It could be the one that makes
>> gc much longer.
>>
>> Generally it's good to minimize object creation and use not too 
>> UNNECESSARILY large JVM heap. What many people practice
>> is to recyle objects and threads.
>>
>>   
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

-- 
------------------------------------------------------------------------
Alexey N. Solofnenko <http://trelony.cjb.net/>
Pleasant Hill, CA (GMT-8 usually)

Mime
View raw message