subject:"\"Re\\\\\\\: Tomcat with 8 GB memory\""

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Joe Nathan wrote:
> Otherwise 64bit machines suck! That;s why 64bit Windows is not 
> popular. I don't them many shops selling!

64-bit Windows is not popular because it costs much more than the 32-bit
versions (though MS will send you a 64-bit upgrade disk for a small fee
if you already own a copy of Vista). Also, most people out there don't
know what the hell a 64-bit OS is.

Next, there are very few 64-bit-compiled applications out there, so the
64-bit OS gets you nothing when you're running 32-bit Office or SQL Server.

The only place that 64-bit OSs make sense really are on servers, and
nobody buys servers from computer shops.

> If you have studied computer science and engineering basics, you
> shouldn't be arguing about slowness of 64bit crunchers!

Wow. joe.bozo = true;

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqe4e9CaO5/Lv0PARAko/AJ9UW2c7cAcAwwDHrHPEI9Fi0dj4QgCfaYpv
2q90zWUe130YKDPMKFdBE2Y=
=3Z0N
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Andrew Miehs



On 27/07/2007, at 12:19 PM, Joe Nathan wrote:

Christopher Schultz-2 wrote:


Joe Nathan wrote:
I would discourage to use such machine! 8GB means you are using  
64 bit

machine which will be much slower than 32 bit machines.

Huh? Why would a 64-bit machine run slower than a 32-bit machine?



Overall performance depend on many things: CPU speed, number of CPUs,
memory size, I/O, especially, virtual memory paging, network interface
bandwidth
64bit machines come with better capacity except
cpu computation speed!


I think what is being forgotten here is that is not a 32bit vs 64bit
theoretical discussion, but rather a comparison of AMD64 vs i386

Sun Java 1.5 64bit has always been quicker in my tests than the 32bit
variation - both running on Debian, both with a similar 2.6 kernel.

AMD64 has a lot more and longer registers than i386 - and I could  
imagine

that the results I have seen are based on this difference..

...

Otherwise 64bit machines suck! That;s why 64bit Windows is not
popular. I don't them many shops selling!


I would assume that is because

A) You need twice as much memory for everything
B) Limited drivers available
C) Games not 64bit...

Performance isn't the issue here...

Andrew



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat with 8 GB memory



Caldarale, Charles R wrote:
> 
>> I don't think JVMs have used stop-the-world GC for some time, now.
> Strictly speaking, they still do, but global suspends occur much, much
> less frequently and for much shorter periods, so in most environments
> it's of negligible impact.
> 
http://www.roselladb.com/dbms.htm Rosella DBMS  is a all java DBMS that can
use up to 512GB+ buffers on heap. 
What it does in the beginning is to allocate multiple-megabyte 
memory blocks to reduce the number of objects, so that 
subsequent garbage collections can deal with very few 
memory objects. It generate very little objects even though
it can deal with tens of millions records.

If you want to use big memory, you have to design to avoid such 
seisures.






-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11826544
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

Christopher Schultz-2 wrote:
> 
> Joe Nathan wrote:
>> I would discourage to use such machine! 8GB means you are using 64 bit
>> machine which will be much slower than 32 bit machines.
> Huh? Why would a 64-bit machine run slower than a 32-bit machine? 
> 

Overall performance depend on many things: CPU speed, number of CPUs,
memory size, I/O, especially, virtual memory paging, network interface
bandwidth 
64bit machines come with better capacity except
cpu computation speed! 

Have you ever tried 64bit Windows desktop or laptop over 32bit machine?
This will tell you exactly. If your application is data intensive, big
memory
over 4GB can work better with reduced I/O operations! Database servers
or WS that support session information of thousands of users over long 
period of time, having big memory improve performance.

If you have studied computer science and engineering basics, you shouldn't
be arguing about slowness of 64bit crunchers!

Otherwise 64bit machines suck! That;s why 64bit Windows is not 
popular. I don't them many shops selling!

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11826413
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Leon Rosenberg

Could you provide some additional information?
So far 64bit machines always outperformed 32bit machines in my
personal benchmarks as well as in third party benchmarks I stumbled
upon.

So it would be great if you could provide some links or explanations.

thank you
leon

On 7/27/07, Joe Nathan <[EMAIL PROTECTED]> wrote:
>
>
> Christopher Schultz-2 wrote:
> >
> > Joe Nathan wrote:
> >> I would discourage to use such machine! 8GB means you are using 64 bit
> >> machine which will be much slower than 32 bit machines.
> > Huh? Why would a 64-bit machine run slower than a 32-bit machine?
> >
>
> Overall performance depend on many things: CPU speed, number of CPUs,
> memory size, I/O, especially, virtual memory paging, network interface
> bandwidth
> 64bit machines come with better capacity except
> cpu computation speed!
>
> Have you ever tried 64bit Windows desktop or laptop over 32bit machine?
> This will tell you exactly. If your application is data intensive, big
> memory
> over 4GB can work better with reduced I/O operations! Database servers
> or WS that support session information of thousands of users over long
> period of time, having big memory improve performance.
>
> If you have studied computer science and engineering basics, you shouldn't
> be arguing about slowness of 64bit crunchers!
>
> Otherwise 64bit machines suck! That;s why 64bit Windows is not
> popular. I don't them many shops selling!
>
>
> --
> View this message in context: 
> http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11826413
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat with 8 GB memory

2007-07-27 Thread Peter Crowther

> From: Joe Nathan [mailto:[EMAIL PROTECTED] 
> Overall performance depend on many things: CPU speed, number of CPUs,
> memory size, I/O, especially, virtual memory paging, network interface
> bandwidth 
> 64bit machines come with better capacity except
> cpu computation speed! 

Please state your references on this - at present, you're asserting it
without showing evidence to back you up.  Excuse us if we're
collectively sceptical when what you're saying goes against our
experiences and you don't supply backup.

> Have you ever tried 64bit Windows desktop or laptop over 
> 32bit machine?

Yep.  Routinely.

> Otherwise 64bit machines suck! That;s why 64bit Windows is not 
> popular. I don't them many shops selling!

64-bit Windows is unpopular because of poor application compatibility,
just as Vista is unpopular because of poor application compatibility.
Few people buy an OS for speed or technical capability; they buy it
because it runs the apps they need/want.

- Peter

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

Leon Rosenberg-3 wrote:
> 
> Could you provide some additional information?
> So far 64bit machines always outperformed 32bit machines in my
> personal benchmarks as well as in third party benchmarks I stumbled
> upon.
> 
> So it would be great if you could provide some links or explanations.
> 
> thank you
> leon
> 

It's for the very simple reason: 64bit machines have 64bit address!
What is address! It's pointers if you are familiar with C, Pointers
are 64bit integers. Pointer arithmetics will deal with 64bit addressed
data. Arithmetic operations on 64bit takes app. twice long as 32bits.
As this is used very many in compiled binaries pointer arithmetics, 
you should expect 64bit machines will give you slower performance, 
for cpu bound applications. Note that hardware clocking time also 
slower than 32 machines.

However, if your application is "data intensive" (with heaps of data
caches),
larger memory can boost quite a lot. You may even get several time
or more better through put than otherwise. That's why there is a push
for 64 bit machine.

Also there is another aspect of programming skills. Many servlet programmers
don't understand underlying garbage collection algorithms. They tend to
make use lot more memory. If you control memory use smartly, 
this can boost performance significantly as well!

regards.

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11837027
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory



ronatartifact wrote:
> 
> This is what Microsoft has to say on 64 bit using Websphere.
> Basically 32bit better for small volume servers that can live with a 2GB 
> memory ceiling.
> 
If you have applications that can benefit from memory bigger thab 2 or 4GB,
your application is data intensive. Having more memory can reduce 
I/Os for both by program and system virtual storage paging. This 
can make huge difference in performance. If you have such applications,
64bit is the one to go. Otherwise, 32 will work better at lower cost!

cheers.

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11837056
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Leon Rosenberg

On 7/27/07, Joe Nathan <[EMAIL PROTECTED]> wrote:
>
>
> Leon Rosenberg-3 wrote:
> >
> > Could you provide some additional information?
> > So far 64bit machines always outperformed 32bit machines in my
> > personal benchmarks as well as in third party benchmarks I stumbled
> > upon.
> >
> > So it would be great if you could provide some links or explanations.
> >
> > thank you
> > leon
> >
>
> It's for the very simple reason: 64bit machines have 64bit address!
> What is address! It's pointers if you are familiar with C, Pointers
> are 64bit integers. Pointer arithmetics will deal with 64bit addressed
> data. Arithmetic operations on 64bit takes app. twice long as 32bits.

Sorry, this just sounds plain wrong. If a 64 bit processor comes with
64 bit register it means that it can make an integer 64 bit addition
(long) in one operation, which is at least twice as fast as the same
operation on a 32 bit processor, and an addition of a 32 bit integer
is as fast as on a 32 bit processor, at least what you see outside of
the processor.

Further, following your argumentation, 16 bit processor is faster than
32 bit processor and 8 bit faster than 16... hell my abacus rocks.

I admit that my last course in processors is like 10 years ago, but we
actually measured the performance of the same application under 64 bit
java on a 64 bit system and 32 bit java on a 32 bit system, and guess
what, the 64 bit version outperformed the 32 bit version by nearly
10%.

Despite empirical data, the simply marketing logic tells us, that 64
bit processors are faster, at least amd and intel. The 64 bit
processors (as they were introduced) were higher priced as the 32 bit
alternatives and were shipped with larger cache and higher tacts. But
the whole discussion is pointless anyway, since there are no
comparable 32 bit processors on market anymore, and would you agree
that a 64 bit application runs faster on a 64 bit processor than a 32
bit application?

> As this is used very many in compiled binaries pointer arithmetics,
> you should expect 64bit machines will give you slower performance,
> for cpu bound applications. Note that hardware clocking time also
> slower than 32 machines.
>
> However, if your application is "data intensive" (with heaps of data
> caches),
> larger memory can boost quite a lot. You may even get several time
> or more better through put than otherwise. That's why there is a push
> for 64 bit machine.
>
> Also there is another aspect of programming skills. Many servlet programmers
> don't understand underlying garbage collection algorithms. They tend to
> make use lot more memory. If you control memory use smartly,
> this can boost performance significantly as well!

Errm WHAT???

regards
Leon

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

Christopher Schultz-2 wrote:
> 
> 64-bit Windows is not popular because it costs much more than the 32-bit
> versions (though MS will send you a 64-bit upgrade disk for a small fee
> if you already own a copy of Vista). Also, most people out there don't
> know what the hell a 64-bit OS is.
> 
> Next, there are very few 64-bit-compiled applications out there, so the
> 64-bit OS gets you nothing when you're running 32-bit Office or SQL
> Server.
> 
> The only place that 64-bit OSs make sense really are on servers, and
> nobody buys servers from computer shops.
> 

If your logic is valid, we should be still using 16bit or 8bit machines!
Retail price between 64bit and 32bit not much difference.
Not many people willing to pay a bit extra for slower running 
systems. Not many s/w developers make 64bit available.
That's what happening on personal machines.

As I mentioned, server can be different. Since many people may use it
simulataneously, there may be a need for bigger main memory. 64bit 
address this market!

regards.

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11837771
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Alexey Solofnenko

I was under impression that GC does not scale linearly. That means one 
8GB process will be slower than two 4GB processes. There are other 
considerations too: multi-threading - global locks will lock less 
threads (maybe in GC, heap, application logic, ...), but cluster 
overhead may be noticeable too.


- Alexey.

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lightbulb,

lightbulb432 wrote:
  

If you have a gigantic server with something like 8 GB of memory, what would
be the best way to run Tomcat 6 on it? One instance, multiple instances, or
divide it up into two or more virtualized servers each with one instance?



Unless you have concerns about stability of TC6 or your own application,
one big JVM with a ton of threads would be my recommendation.
Virtualization or multiple TC instances only adds overhead with no other
real benefit. (If you run multiple applications, multiple TC instances
might make sense).

  

Is Tomcat meant to run as one instance with that much memory, or is it
optimized for a different amount of memory?



Tomcat shouldn't care. I think that thread synchronization is faster
than full context switching, but that can be very sensitive to the
platform, OS, and tuning parameters you might have (in the OS). Java is
perfectly happy to run with 8GB.

  

I realize with the options I mentioned above there are implications
regarding high-availability and performance, but I'm not sure exactly what
they'd be. Perhaps someone with more knowledge of this kind of stuff could
comment.



If you trust your operating system (I would trust any UNIX and UNIX-like
OS, and Windows is somewhat dependable if you don't ask it to do too
many things), then a single instance of the OS on a lot of hardware is
just fine: go for it.

If you are concerned about your OS's stability, then by all means run
multiple instances of the OS and load balance between. From a strict
performance standpoint, less is more, so stick to one OS and one Tomcat
instance on that big, fat machine.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqOyq9CaO5/Lv0PARAlTDAJwKFLgizNh/MatDmEupjdLvLvvDWgCfbHSj
XLO50tctVgV5w+N/qwYYZEQ=
=DJLh
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  


--

Alexey N. Solofnenko 
Pleasant Hill, CA (GMT-8 usually)


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Tomcat with 8 GB memory

2007-07-27 Thread Andrew Miehs



On 27/07/2007, at 11:30 PM, Joe Nathan wrote:


It's for the very simple reason: 64bit machines have 64bit address!
What is address! It's pointers if you are familiar with C, Pointers
are 64bit integers. Pointer arithmetics will deal with 64bit addressed
data. Arithmetic operations on 64bit takes app. twice long as 32bits.
As this is used very many in compiled binaries pointer arithmetics,
you should expect 64bit machines will give you slower performance,
for cpu bound applications. Note that hardware clocking time also
slower than 32 machines.


You may find this interesting...

quoting from wikipedia... http://en.wikipedia.org/wiki/X86-64


Full support for 64-bit integers: All general-purpose registers  
(GPRs) are expanded from 32 bits to 64 bits, and all arithmetic and  
logical operations, memory-to-register and register-to-memory  
operations, etc., are now directly supported for 64-bit integers.  
Pushes and pops on the stack are always in eight-byte strides, and  
pointers are eight bytes wide.



Additional registers: In addition to increasing the size of the  
general-purpose registers, the number of named general-purpose  
registers is increased from eight (i.e.  
eax,ebx,ecx,edx,ebp,esp,esi,edi) in x86-32 to 16. It is therefore  
possible to keep more local variables in registers rather than on the  
stack, and to let registers hold frequently accessed constants;  
arguments for small and fast subroutines may also be passed in  
registers to a greater extent. However, more registers also involves  
more saving and restoring of register contents, and AMD64 still has  
fewer registers than many common RISC processors (which typically  
have 31–64 registers) or VLIW-like machines such as the IA-64 (which  
has 128 registers).



Cheers

Adrew

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

Leon Rosenberg-3 wrote:
> 
> Sorry, this just sounds plain wrong. If a 64 bit processor comes with
> 64 bit register it means that it can make an integer 64 bit addition
> (long) in one operation, 
> 

It does in single operation, but it taks twices clock pulse than 32bit!
You cannot perform binary adder operation in parallel. Speed of operation
is measured with the number of clock pulse. 32bit adder may require 
something like 36 clock pulses or close numbers. 64bit require about 70
clock
pulses. Remember that cpu logic gates work in sync with clocks.
Limited number of operations can be performed in a second. The 
number will change depending on your cpu clock pulse, which 
is limited to about 3.5GHz these days. That's why we want more Hz
to get speed. That's the thing that give us the speed!

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11838049
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread David Smith

I had a processor design class and know very well the actual gate design 
in bit arithmetic.  Aside from the propagation of the carry bit taking a 
teeny, tiny bit longer in 64 bit arithmetic, it still occurs in a single 
clock cycle. 

Further, primitive data type sizes in java are very clearly defined by 
the language specification (java language spec ver. 3, section 4.2) and 
will not change size just because the JVM is in a 64-bit environment.  
Hmm... just thought of an interesting point.  Long integers and double 
precision floats will actually process faster because the CPU can 
swallow them whole as opposed to handling them in two or more cycles. 

Pile on multiple cores, pipeline architecture, and two levels of cache 
and it becomes obvious to me the performance isn't hit at all by 64-bit 
operation.


--David

Leon Rosenberg wrote:

On 7/27/07, Joe Nathan <[EMAIL PROTECTED]> wrote:
  

Leon Rosenberg-3 wrote:


Could you provide some additional information?
So far 64bit machines always outperformed 32bit machines in my
personal benchmarks as well as in third party benchmarks I stumbled
upon.

So it would be great if you could provide some links or explanations.

thank you
leon

  

It's for the very simple reason: 64bit machines have 64bit address!
What is address! It's pointers if you are familiar with C, Pointers
are 64bit integers. Pointer arithmetics will deal with 64bit addressed
data. Arithmetic operations on 64bit takes app. twice long as 32bits.



Sorry, this just sounds plain wrong. If a 64 bit processor comes with
64 bit register it means that it can make an integer 64 bit addition
(long) in one operation, which is at least twice as fast as the same
operation on a 32 bit processor, and an addition of a 32 bit integer
is as fast as on a 32 bit processor, at least what you see outside of
the processor.

Further, following your argumentation, 16 bit processor is faster than
32 bit processor and 8 bit faster than 16... hell my abacus rocks.

I admit that my last course in processors is like 10 years ago, but we
actually measured the performance of the same application under 64 bit
java on a 64 bit system and 32 bit java on a 32 bit system, and guess
what, the 64 bit version outperformed the 32 bit version by nearly
10%.

Despite empirical data, the simply marketing logic tells us, that 64
bit processors are faster, at least amd and intel. The 64 bit
processors (as they were introduced) were higher priced as the 32 bit
alternatives and were shipped with larger cache and higher tacts. But
the whole discussion is pointless anyway, since there are no
comparable 32 bit processors on market anymore, and would you agree
that a 64 bit application runs faster on a 64 bit processor than a 32
bit application?


  

As this is used very many in compiled binaries pointer arithmetics,
you should expect 64bit machines will give you slower performance,
for cpu bound applications. Note that hardware clocking time also
slower than 32 machines.

However, if your application is "data intensive" (with heaps of data
caches),
larger memory can boost quite a lot. You may even get several time
or more better through put than otherwise. That's why there is a push
for 64 bit machine.

Also there is another aspect of programming skills. Many servlet programmers
don't understand underlying garbage collection algorithms. They tend to
make use lot more memory. If you control memory use smartly,
this can boost performance significantly as well!



Errm WHAT???



regards
Leon

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Joe Nathan wrote:
> Arithmetic operations on 64bit takes app. twice long as 32bits.

You are out of your mind.

> Note that hardware clocking time also
> slower than 32 machines.

Clock speed has nothing to do with integer width.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqn149CaO5/Lv0PARAjArAJ9c4cLsLAJp1n4ysPvPnqqcISGqcgCcCkK5
+Toxx7MbZA0JOOTKLaIwgUU=
=4St0
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Len Popp

On 7/27/07, Joe Nathan <[EMAIL PROTECTED]> wrote:
> It does in single operation, but it taks twices clock pulse than 32bit!
> You cannot perform binary adder operation in parallel. Speed of operation
> is measured with the number of clock pulse. 32bit adder may require
> something like 36 clock pulses or close numbers. 64bit require about 70
> clock
> pulses. Remember that cpu logic gates work in sync with clocks.
> Limited number of operations can be performed in a second. The
> number will change depending on your cpu clock pulse, which
> is limited to about 3.5GHz these days. That's why we want more Hz
> to get speed. That's the thing that give us the speed!

That is wrong. Integer addition *is* done in parallel by any normal
CPU. Here's a description of one type of logic circuit to do that:
http://en.wikipedia.org/wiki/Carry_look-ahead_adder
The computer I'm using to type this takes one clock cycle to add a
pair of integers that are in registers, whether they're 64, 32, 16 or
8 bits wide.
Reference: "Software Optimization Guide for AMD Family 10h
Processors", Appendix C
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf
-- 
Len

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Joe Nathan wrote:
> If your logic is valid, we should be still using 16bit or 8bit machines!

The reverse is true. First of all, no home user ever bought an 8-bit
machine. The 8086 (the first Intel 16-bit machine) was eventually
replaced by the 80386 series of microprocessors -- the first 32-bit
ones. It's been a lng time since those have been available.

I think you'd have to admit that the 80386 went faster than the 8086,
and not just because of clock speed increases.

> Retail price between 64bit and 32bit not much difference.

Dell only ships the 64-bit version of Microsoft Windows Vista "Ultimate"
- -- all others are 32-bit versions. Nobody is going to pay the
difference, which ends up being around $200, to get more OS features.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqn7l9CaO5/Lv0PARAl0aAJ9fN/RB/I22zDPRzXwRP3Fjt1hAdgCgpqD7
A7T64V5BKH/nyDKXq0sxCag=
=Mesx
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

Joe Nathan wrote:
> 
> Leon Rosenberg-3 wrote:
>> Sorry, this just sounds plain wrong. If a 64 bit processor comes
>> with 64 bit register it means that it can make an integer 64 bit
>> addition (long) in one operation,
> 
> It does in single operation, but it taks twices clock pulse than
> 32bit!

Okay, I think it's time someone ask /you/ to take a look at "computer
science and engineering". You ovsiouly have no idea what you are talking
about.

> You cannot perform binary adder operation in parallel. Speed of
> operation is measured with the number of clock pulse. 32bit adder may
> require something like 36 clock pulses or close numbers. 64bit
> require about 70 clock pulses.

Thank god you aren't designing microprocessors. 64-bit machines don't
use 32-bit adders. They use 64-bit adders, which is why it's virtually
identical in performance.

I'm not playing this stupid game any more. Joe Nathan is nothing but a
troll. :p

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqn+u9CaO5/Lv0PARAsM6AKCciFtDuM9GBDsNO8970yVy4loGZQCgpQ+p
2IBpK0zafMrryy9A6eVxD8o=
=+Ex0
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat with 8 GB memory

2007-07-27 Thread Caldarale, Charles R

> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] 
> Subject: Re: Tomcat with 8 GB memory
> 
> I was under impression that GC does not scale linearly. That 
> means one 8GB process will be slower than two 4GB processes.

Not true.  The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view.  (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-27 Thread Alexey Solofnenko

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.


- Alexey.

Caldarale, Charles R wrote:
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] 
Subject: Re: Tomcat with 8 GB memory


I was under impression that GC does not scale linearly. That 
means one 8GB process will be slower than two 4GB processes.



Not true.  The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view.  (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  


--

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


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Tomcat with 8 GB memory

Caldarale, Charles R wrote:
> 
>> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] 
>> Subject: Re: Tomcat with 8 GB memory
>> 
>> I was under impression that GC does not scale linearly. That 
>> means one 8GB process will be slower than two 4GB processes.
> Not true.  The time of a full GC using modern algorithms depends mostly
> on the number and type of live objects, not the amount of heap space.
> The number and type of live (reachable) objects stays relatively
> constant for most application once the ramp-up period is over.
> Consequently, running a single JVM with the largest heap you can fit in
> the process space is the most efficient from a GC point of view.  (Of
> course, there are plenty of other reasons not to put all your eggs in
> one basket.)
> 

There are several factors that matters for GC: number of objects,
number of object references, size of objects. All matters! As number of
objects get bigger, it tends to have more reference. Size of objects?
This does matter when heap compression is involved, 
objects have to be moved.

In addition, keep in mind that your heap memory is on virtual memory.
While doing GC analysis, if you don't have enough main memory, this
can create caos.

I have a system that create a number of objects that allocate sizable
memory. When it hit a simple write (may read also) operation, it then goes
mad! This happens on Windows! But I don't know what's wrong with it.
For about 10 ~ 20 minutes, it stop everything and does I/O only
until the dust clears! 

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11839794
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

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.

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11839991
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-28 Thread Ron Wheeler

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-28 Thread Alexey Solofnenko


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--

Alexey N. Solofnenko 
Pleasant Hill, CA (GMT-8 usually)


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Tomcat with 8 GB memory

2007-07-28 Thread Ron Wheeler

Why would you write down something in a serious forum that you just made 
up with no basis in fact.
This is just fantasy that you could not have found anywhere unless it 
was in a satirical send-up on science and technology.


If any of your stuff was even remotely true, then the top scientists and 
engineers at Intel, AMD, Microsoft, Sun, IBM, HP, etc. are all idiots.

That should have given you pause right at the start.
If you get into a situation where you are the only smart guy in a world 
full of highly paid idiots who magically seem to be producing faster 
computers in spite of their ignorance of a basic truth that only you 
know, you might want to reconsider the situation.


Ron

Joe Nathan wrote:

Leon Rosenberg-3 wrote:
  

Sorry, this just sounds plain wrong. If a 64 bit processor comes with
64 bit register it means that it can make an integer 64 bit addition
(long) in one operation, 




It does in single operation, but it taks twices clock pulse than 32bit!
You cannot perform binary adder operation in parallel. Speed of operation
is measured with the number of clock pulse. 32bit adder may require 
something like 36 clock pulses or close numbers. 64bit require about 70

clock
pulses. Remember that cpu logic gates work in sync with clocks.
Limited number of operations can be performed in a second. The 
number will change depending on your cpu clock pulse, which 
is limited to about 3.5GHz these days. That's why we want more Hz

to get speed. That's the thing that give us the speed!




  


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-28 Thread Ron Wheeler


2GB is the limit for 32 bit applications.

Ron

Joe Nathan wrote:

ronatartifact wrote:
  

This is what Microsoft has to say on 64 bit using Websphere.
Basically 32bit better for small volume servers that can live with a 2GB 
memory ceiling.




If you have applications that can benefit from memory bigger thab 2 or 4GB,
your application is data intensive. Having more memory can reduce 
I/Os for both by program and system virtual storage paging. This 
can make huge difference in performance. If you have such applications,

64bit is the one to go. Otherwise, 32 will work better at lower cost!

cheers.

  


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat with 8 GB memory

2007-07-28 Thread Caldarale, Charles R

> From: Ron Wheeler [mailto:[EMAIL PROTECTED] 
> Subject: Re: Tomcat with 8 GB memory
> 
> 2GB is the limit for 32 bit applications.

Minor correction: some versions of 32-bit Windows Server have a
boot-time option to use 3 GB for each user process, which allows a
slightly bigger JVM heap.  (The virtual space is badly fragmented by
DLLs, so it doesn't buy as much room as one would expect.)  Still in the
noise range compared to what's available with a 64-bit platform.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat with 8 GB memory

2007-07-28 Thread Caldarale, Charles R

> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] 
> Subject: Re: Tomcat with 8 GB memory
> 
> No, each of two 4GB processes will have only a half of the 
> objects under the same load.

There's a significant amount of objects created by the container and the
webapps that are essentially permanent; with two JVM instances, you now
have two copies of these, not just one.  The number of short-lived
objects in existence during request processing is dependent on the
number of concurrent requests, but not directly on the rate of requests.

> And I heard that GC does not scale linear with heap size.

This was true in the days of primitive GC algorithms, but the current
ones are little affected by gross heap size.  Having labored under the
old belief myself, I was somewhat surprised when measurements showed
only very minor variations with different heap sizes.  (That probably
has more to do with the lower L1/L2/L3 cache hit rates when using larger
heaps rather than something inherent in the GC algorithms themselves.)

> And this is without multi-threading performance considerations.

Note that modern GC operations are parallelized, so reducing the number
of CPU resources available by running multiple JVMs causes a given GC to
run longer.  There is little interaction among the parallel GC threads,
so lock conflicts and cache invalidations don't impact GC much.  (Which
says nothing about whether or not a given app can benefit from more CPUs
being available.)

> As usual, your mileage may vary and only tests can tell for sure.

Most definitely.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-28 Thread Alexey Solofnenko

I can only tell that we run performance testing for our platform and 
found that best performance was achieved by using a separate server per  
user (reusable pool). However the memory requirements were abysmal, so 
we are running two processes in parallel by default achieving good 
performance without requiring much more memory. But unlike [most] web 
applications we have a lot of long lived objects and maybe 
synchronization issues are the major factor in our case. That is why I 
say that only performance tests can say for sure.


- Alexey.

Caldarale, Charles R wrote:
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] 
Subject: Re: Tomcat with 8 GB memory


No, each of two 4GB processes will have only a half of the 
objects under the same load.



There's a significant amount of objects created by the container and the
webapps that are essentially permanent; with two JVM instances, you now
have two copies of these, not just one.  The number of short-lived
objects in existence during request processing is dependent on the
number of concurrent requests, but not directly on the rate of requests.

  

And I heard that GC does not scale linear with heap size.



This was true in the days of primitive GC algorithms, but the current
ones are little affected by gross heap size.  Having labored under the
old belief myself, I was somewhat surprised when measurements showed
only very minor variations with different heap sizes.  (That probably
has more to do with the lower L1/L2/L3 cache hit rates when using larger
heaps rather than something inherent in the GC algorithms themselves.)

  

And this is without multi-threading performance considerations.



Note that modern GC operations are parallelized, so reducing the number
of CPU resources available by running multiple JVMs causes a given GC to
run longer.  There is little interaction among the parallel GC threads,
so lock conflicts and cache invalidations don't impact GC much.  (Which
says nothing about whether or not a given app can benefit from more CPUs
being available.)

  

As usual, your mileage may vary and only tests can tell for sure.



Most definitely.

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  


--

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Tomcat with 8 GB memory

Some of arguments presented hold some truths, but look at the bigger 
picture... the point is that 64bit is a superior architecture to 32 bit, 
but it is still maturing... the reasons for this are both hardware and 
software related... the way we write programs will have to change to 
take advantage of the new architecture, and the current generation of 
hardware will no doubt mature to realize the potential of 64bit 
architecture.


32 bits processors can represent numbers up to 4,294,967,295 while a 
64-bit machine can represent numbers up to 18,446,744,073,709,551,615. 
For modern hardware to take advantage of the processing power of the 64 
bit architecture a system must have a minimum 4GB Ram, but probably 
needs significantly more and more importantly the CAPACITY to take full 
advantage of it, allocating it to running processes, with less there is 
potential for lag. 

64bit machines have been around since the 60's but only now are software 
and hardware vendors supporting it for the mainstream market. So is 
64bit better than 32bit right now? the answer is yes, a 64-bit processor 
has more technology, a better design with more transistors, thus faster 
speeds are possible. This is currently where the true benefit of 
switching to a 64-bit processor lays, it has nothing to do with the 
memory address space, which is exactly that, just space for more complex 
computations.


Peter


Alexey Solofnenko 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.


- Alexey.

Caldarale, Charles R wrote:
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re: 
Tomcat with 8 GB memory


I was under impression that GC does not scale linearly. That means 
one 8GB process will be slower than two 4GB processes.



Not true.  The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view.  (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  




--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652 

If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Andrew Miehs


On 29/07/2007, at 2:34 PM, Peter Stavrinides wrote:


32 bits processors can represent numbers up to 4,294,967,295 while  
a 64-bit machine can represent numbers up to  
18,446,744,073,709,551,615. For modern hardware to take advantage  
of the processing power of the 64 bit architecture a system must  
have a minimum 4GB Ram, but probably needs significantly more and  
more importantly the CAPACITY to take full advantage of it,  
allocating it to running processes, with less there is potential  
for lag.
64bit machines have been around since the 60's but only now are  
software and hardware vendors supporting it for the mainstream  
market. So is 64bit better than 32bit right now? the answer is yes,  
a 64-bit processor has more technology, a better design with more  
transistors, thus faster speeds are possible. This is currently  
where the true benefit of switching to a 64-bit processor lays, it  
has nothing to do with the memory address space, which is exactly  
that, just space for more complex computations.


This is definitely not looking at the big picture.

Whether or not to go 64bit depends on your application.

BASED ON MY TESTS

If your application runs in Java AND you are using Sun JVM 1.5 AND  
performance is an issue, then I would definitely go 64bit linux.


else if your Java application doesn't have a performance requirement,  
but needs lots of memory, be that for caching or anything else, then

I would use 64 bit - Pick your own operating system...

else if the machine you are using has more than 4GB RAM, I would look  
at using a 64bit OS, - up to you whether you want 32bit or 64bit Java.


else if none of this applies to you, I would probably run a 32 bit  
OS, and wait for someone to port the last remaining packages/ drivers.



BTW More transistors mean less CPU clock speed - not more... (But I  
think you meant larger operations per cycle).


Cheers

Andrew

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Ron Wheeler




This is a Tomcat forum  so lets focus on the role of memory in a Servlet 
Engine.

Read the Microsoft paper.
http://msdn2.microsoft.com/en-us/vstudio/aa700838.aspx

Bigger memory space means better  performance when you have large 
numbers of  users.
If you are designing a Tomcat application for a hundred users, you can 
take whatever you want (or can find) for hardware.
If you are hoping to handle thousands of users, you will be a lot better 
off on 64 bits.
The faster arithmetic of 64 bits is not as important as the ability to 
use more than 2Gb (Windows) or 4GB (Linux) of memory for your Tomcat 
application and cache, transaction buffers, etc.


Here is IBM's view on how Linux works in a 32 bit environment. You can 
see the gyrations that have to be done to arrange processes in a 32 bit 
world.

http://www.ibm.com/developerworks/linux/library/l-memmod/


From a strategic point of view, 64 bit is clearly the way of the future 
and each new version of the OS, Java VM and all of the supporting 
libraries will have more optimization for 64 bit memory management and 
arithmetic.


The leaders in Web technology have already moved to 64 bits, the rest of 
us will follow.


It is not clear that you can even purchase a server from the major 
vendors that does not have a 64 bit processor. I did not see any 32 bit 
servers at HP.

If 64 bit was not a competitive advantage this would not happen.


Ron

Andrew Miehs wrote:

On 29/07/2007, at 2:34 PM, Peter Stavrinides wrote:


32 bits processors can represent numbers up to 4,294,967,295 while a 
64-bit machine can represent numbers up to 
18,446,744,073,709,551,615. For modern hardware to take advantage of 
the processing power of the 64 bit architecture a system must have a 
minimum 4GB Ram, but probably needs significantly more and more 
importantly the CAPACITY to take full advantage of it, allocating it 
to running processes, with less there is potential for lag.
64bit machines have been around since the 60's but only now are 
software and hardware vendors supporting it for the mainstream 
market. So is 64bit better than 32bit right now? the answer is yes, a 
64-bit processor has more technology, a better design with more 
transistors, thus faster speeds are possible. This is currently where 
the true benefit of switching to a 64-bit processor lays, it has 
nothing to do with the memory address space, which is exactly that, 
just space for more complex computations.


This is definitely not looking at the big picture.

Whether or not to go 64bit depends on your application.

BASED ON MY TESTS

If your application runs in Java AND you are using Sun JVM 1.5 AND 
performance is an issue, then I would definitely go 64bit linux.


else if your Java application doesn't have a performance requirement, 
but needs lots of memory, be that for caching or anything else, then

I would use 64 bit - Pick your own operating system...

else if the machine you are using has more than 4GB RAM, I would look 
at using a 64bit OS, - up to you whether you want 32bit or 64bit Java.


else if none of this applies to you, I would probably run a 32 bit OS, 
and wait for someone to port the last remaining packages/ drivers.



BTW More transistors mean less CPU clock speed - not more... (But I 
think you meant larger operations per cycle).


Cheers

Andrew

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Mohan2005


Hello:

we also wish to convert out 32bit dual cores to 64bit dual cores to run java
applications (multiple instances with large JVM memory)
but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
JVM.
why? and if true how to overcome??

thanks



Peter Stavrinides wrote:
> 
> Some of arguments presented hold some truths, but look at the bigger 
> picture... the point is that 64bit is a superior architecture to 32 bit, 
> but it is still maturing... the reasons for this are both hardware and 
> software related... the way we write programs will have to change to 
> take advantage of the new architecture, and the current generation of 
> hardware will no doubt mature to realize the potential of 64bit 
> architecture.
> 
> 32 bits processors can represent numbers up to 4,294,967,295 while a 
> 64-bit machine can represent numbers up to 18,446,744,073,709,551,615. 
> For modern hardware to take advantage of the processing power of the 64 
> bit architecture a system must have a minimum 4GB Ram, but probably 
> needs significantly more and more importantly the CAPACITY to take full 
> advantage of it, allocating it to running processes, with less there is 
> potential for lag. 
> 
> 64bit machines have been around since the 60's but only now are software 
> and hardware vendors supporting it for the mainstream market. So is 
> 64bit better than 32bit right now? the answer is yes, a 64-bit processor 
> has more technology, a better design with more transistors, thus faster 
> speeds are possible. This is currently where the true benefit of 
> switching to a 64-bit processor lays, it has nothing to do with the 
> memory address space, which is exactly that, just space for more complex 
> computations.
> 
> Peter
> 
> 
> Alexey Solofnenko 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.
>>
>> - Alexey.
>>
>> Caldarale, Charles R wrote:
>>>> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re: 
>>>> Tomcat with 8 GB memory
>>>>
>>>> I was under impression that GC does not scale linearly. That means 
>>>> one 8GB process will be slower than two 4GB processes.
>>>> 
>>>
>>> Not true.  The time of a full GC using modern algorithms depends mostly
>>> on the number and type of live objects, not the amount of heap space.
>>> The number and type of live (reachable) objects stays relatively
>>> constant for most application once the ramp-up period is over.
>>> Consequently, running a single JVM with the largest heap you can fit in
>>> the process space is the most efficient from a GC point of view.  (Of
>>> course, there are plenty of other reasons not to put all your eggs in
>>> one basket.)
>>>
>>>  - 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 start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>   
>>
> 
> -- 
> Peter Stavrinides
> Albourne Partners (Cyprus) Ltd
> Tel: +357 22 750652 
> 
> If you are not an intended recipient of this e-mail, please notify the
> sender, delete it and do not read, act upon, print, disclose, copy, retain
> or redistribute it. Please visit http://www.albourne.com/email.html for
> important additional terms relating to this e-mail. 
> 
> 
> 
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11853960
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread David Smith


"...but people advice that 64bit are 20 - 30% slower than the 32bit ..."

Could these people offer any evidence to this?  Cite any benchmarks?  I 
would like to see the evidence of this before believing it to be true.


--David

Mohan2005 wrote:

Hello:

we also wish to convert out 32bit dual cores to 64bit dual cores to run java
applications (multiple instances with large JVM memory)
but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
JVM.
why? and if true how to overcome??

thanks



Peter Stavrinides wrote:
  
Some of arguments presented hold some truths, but look at the bigger 
picture... the point is that 64bit is a superior architecture to 32 bit, 
but it is still maturing... the reasons for this are both hardware and 
software related... the way we write programs will have to change to 
take advantage of the new architecture, and the current generation of 
hardware will no doubt mature to realize the potential of 64bit 
architecture.


32 bits processors can represent numbers up to 4,294,967,295 while a 
64-bit machine can represent numbers up to 18,446,744,073,709,551,615. 
For modern hardware to take advantage of the processing power of the 64 
bit architecture a system must have a minimum 4GB Ram, but probably 
needs significantly more and more importantly the CAPACITY to take full 
advantage of it, allocating it to running processes, with less there is 
potential for lag. 

64bit machines have been around since the 60's but only now are software 
and hardware vendors supporting it for the mainstream market. So is 
64bit better than 32bit right now? the answer is yes, a 64-bit processor 
has more technology, a better design with more transistors, thus faster 
speeds are possible. This is currently where the true benefit of 
switching to a 64-bit processor lays, it has nothing to do with the 
memory address space, which is exactly that, just space for more complex 
computations.


Peter


Alexey Solofnenko 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.


- Alexey.

Caldarale, Charles R wrote:
  
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re: 
Tomcat with 8 GB memory


I was under impression that GC does not scale linearly. That means 
one 8GB process will be slower than two 4GB processes.

  

Not true.  The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view.  (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  


--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652 


If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Please visit http://www.albourne.com/email.html for
important additional terms relating to this e-mail. 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Leon Rosenberg

On 7/29/07, Mohan2005 <[EMAIL PROTECTED]> wrote:
>
> Hello:
>
> we also wish to convert out 32bit dual cores to 64bit dual cores to run java
> applications (multiple instances with large JVM memory)
> but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
> JVM.
> why? and if true how to overcome??
>

dont listen to that people they are talking bullshit :-)
Leon

> thanks
>
>
>
> Peter Stavrinides wrote:
> >
> > Some of arguments presented hold some truths, but look at the bigger
> > picture... the point is that 64bit is a superior architecture to 32 bit,
> > but it is still maturing... the reasons for this are both hardware and
> > software related... the way we write programs will have to change to
> > take advantage of the new architecture, and the current generation of
> > hardware will no doubt mature to realize the potential of 64bit
> > architecture.
> >
> > 32 bits processors can represent numbers up to 4,294,967,295 while a
> > 64-bit machine can represent numbers up to 18,446,744,073,709,551,615.
> > For modern hardware to take advantage of the processing power of the 64
> > bit architecture a system must have a minimum 4GB Ram, but probably
> > needs significantly more and more importantly the CAPACITY to take full
> > advantage of it, allocating it to running processes, with less there is
> > potential for lag.
> >
> > 64bit machines have been around since the 60's but only now are software
> > and hardware vendors supporting it for the mainstream market. So is
> > 64bit better than 32bit right now? the answer is yes, a 64-bit processor
> > has more technology, a better design with more transistors, thus faster
> > speeds are possible. This is currently where the true benefit of
> > switching to a 64-bit processor lays, it has nothing to do with the
> > memory address space, which is exactly that, just space for more complex
> > computations.
> >
> > Peter
> >
> >
> > Alexey Solofnenko 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.
> >>
> >> - Alexey.
> >>
> >> Caldarale, Charles R wrote:
> >>>> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re:
> >>>> Tomcat with 8 GB memory
> >>>>
> >>>> I was under impression that GC does not scale linearly. That means
> >>>> one 8GB process will be slower than two 4GB processes.
> >>>>
> >>>
> >>> Not true.  The time of a full GC using modern algorithms depends mostly
> >>> on the number and type of live objects, not the amount of heap space.
> >>> The number and type of live (reachable) objects stays relatively
> >>> constant for most application once the ramp-up period is over.
> >>> Consequently, running a single JVM with the largest heap you can fit in
> >>> the process space is the most efficient from a GC point of view.  (Of
> >>> course, there are plenty of other reasons not to put all your eggs in
> >>> one basket.)
> >>>
> >>>  - 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 start a new topic, e-mail: users@tomcat.apache.org
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>
> >
> > --
> > Peter Stavrinides
> > Albourne Partners (Cyprus) Ltd
> > Tel: +357 22 750652
> >
> > If you are not an intended recipient of this e-mail, please notify the
> > sender, delete it and do not read, act upon, print, disclose, copy, retain
> > or redistribute it. Please visit http://www.albourne.com/email.html for
> > important additional terms relating to this e-mail.
> >
> >
> >
> > -
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context: 
> http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11853960
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Andrew Miehs



On 29/07/2007, at 9:08 PM, David Smith wrote:

"...but people advice that 64bit are 20 - 30% slower than the  
32bit ..."


Could these people offer any evidence to this?  Cite any  
benchmarks?  I would like to see the evidence of this before  
believing it to be true.




We did test with out application - (running more than 10 tomcats  
using F5s for Load balancing) and came to the belief that we could  
deal with 15% more users online at the same time. As I said, though,  
this was OUR application - maybe yours is different...


For our purposes however we also found Intel 5160s packed more punch  
per $ than AMD Opterons - (Thankfully we don't have to worry about  
paying the power bills in our colocation)...


Cheers

Andrew

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Ron Wheeler

If you read the references that I posted, you will see when 32 bit is 
faster than 64 bit.
You are not the first guy to ask the question so Microsoft did a pretty 
nice test.


Why is no major hardware vendor selling 32 bit servers for business 
applications? If 32 bit was faster, cheaper and they already have lots 
of chips and manufacturing infrastructure, the guy selling 32 bit 
servers would be killing the rest of the vendors in sales and profits.
HP is not going to spend billions to put out a product line that can not 
compete with IBM's old servers and is slower than HP's existing products.



Mohan2005 wrote:

Hello:

we also wish to convert out 32bit dual cores to 64bit dual cores to run java
applications (multiple instances with large JVM memory)
but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
JVM.
why? and if true how to overcome??

thanks

  


Just ignore the these people. They are talking through their hats or 
about some weird example that does not reflect servlet engine 
performance except at low volumes. There is some overhead in handling 
big address spaces.
Everyone knows that it takes a lot longer to format a 320Gb drive than 
an 80 GB drive but if you could get either for the same price, you would 
take the big drive MOST of the time.
Anyone who buys a dedicated server with 4 GB of memory to run Tomcat 
under 32 bit Windows OS where the space available is only 2GB, is being 
silly. If you want to go past 2GB, you need to be fully 64bit compatible 
right up through the whole stack.
You do need to run a 64 bit OS and a 64 bit JVM to get the advantages of 
64 bit memory addressing capability.


The Microsoft study used Websphere which I understand to be very close 
to Tomcat.


If this were not a Tomcat forum but was oriented to engineering 
simulations, we would be carrying on about floating-point arithmetic 
advantages of a machine that has 64 bit internal data paths.
For Tomcat is is all about address space for caching user requests and 
responses and back-end transactions. It is getting the right hardware 
and software architecture to use the entire RAM optimally for serving 
web pages.


Ron


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Ron Wheeler

Caldarale, Charles R wrote:
From: Ron Wheeler [mailto:[EMAIL PROTECTED] 
Subject: Re: Tomcat with 8 GB memory

2GB is the limit for 32 bit applications.

Minor correction: some versions of 32-bit Windows Server have a
boot-time option to use 3 GB for each user process, which allows a
slightly bigger JVM heap.  (The virtual space is badly fragmented by
DLLs, so it doesn't buy as much room as one would expect.)  Still in the
noise range compared to what's available with a 64-bit platform.

 - Chuck

Apparently Microsoft was not aware of this in their benchmark group, so it is 
good to know to be careful when buying older MS server products. The Windows 
2003 server has a 64 bit version apparently.
I am pretty much focused on Linux and am installing the 64 bit version when I 
have new hardware.

Ron

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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

2007-07-29 Thread Peng Tuck Kwok

On 7/30/07, Ron Wheeler <[EMAIL PROTECTED]> wrote:
>
> I
> The Microsoft study used Websphere which I understand to be very close
> to Tomcat.
>
>
Don't think they are remotely related, other than the fact that they both
can function as containers for java web applications :D

Re: Tomcat with 8 GB memory

From your comments Ron you obviously didn't understand a thing I wrote,
because you have just repeated me!

Andrew Miehs wrote:

On 29/07/2007, at 2:34 PM, Peter Stavrinides wrote:

32 bits processors can represent numbers up to 4,294,967,295 while a
64-bit machine can represent numbers up to
18,446,744,073,709,551,615. For modern hardware to take advantage of
the processing power of the 64 bit architecture a system must have a
minimum 4GB Ram, but probably needs significantly more and more
importantly the CAPACITY to take full advantage of it, allocating it
to running processes, with less there is potential for lag.
64bit machines have been around since the 60's but only now are
software and hardware vendors supporting it for the mainstream
market. So is 64bit better than 32bit right now? the answer is yes, a
64-bit processor has more technology, a better design with more
transistors, thus faster speeds are possible. This is currently where
the true benefit of switching to a 64-bit processor lays, it has
nothing to do with the memory address space, which is exactly that,
just space for more complex computations.

This is definitely not looking at the big picture.

Whether or not to go 64bit depends on your application.

BASED ON MY TESTS

If your application runs in Java AND you are using Sun JVM 1.5 AND
performance is an issue, then I would definitely go 64bit linux.

else if your Java application doesn't have a performance requirement,
but needs lots of memory, be that for caching or anything else, then

I would use 64 bit - Pick your own operating system...

else if the machine you are using has more than 4GB RAM, I would look
at using a 64bit OS, - up to you whether you want 32bit or 64bit Java.

else if none of this applies to you, I would probably run a 32 bit OS,
and wait for someone to port the last remaining packages/ drivers.

BTW More transistors mean less CPU clock speed - not more... (But I
think you meant larger operations per cycle).

Cheers

Andrew

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory

This is really not true, (unless the machine in question is more than 
four years then performance is faster for some operations and slower for 
others), with a new machine you will gain.


Mohan2005 wrote:

Hello:

we also wish to convert out 32bit dual cores to 64bit dual cores to run java
applications (multiple instances with large JVM memory)
but people advice that 64bit are 20 - 30% slower than the 32bit with smaller
JVM.
why? and if true how to overcome??

thanks



Peter Stavrinides wrote:
  
Some of arguments presented hold some truths, but look at the bigger 
picture... the point is that 64bit is a superior architecture to 32 bit, 
but it is still maturing... the reasons for this are both hardware and 
software related... the way we write programs will have to change to 
take advantage of the new architecture, and the current generation of 
hardware will no doubt mature to realize the potential of 64bit 
architecture.


32 bits processors can represent numbers up to 4,294,967,295 while a 
64-bit machine can represent numbers up to 18,446,744,073,709,551,615. 
For modern hardware to take advantage of the processing power of the 64 
bit architecture a system must have a minimum 4GB Ram, but probably 
needs significantly more and more importantly the CAPACITY to take full 
advantage of it, allocating it to running processes, with less there is 
potential for lag. 

64bit machines have been around since the 60's but only now are software 
and hardware vendors supporting it for the mainstream market. So is 
64bit better than 32bit right now? the answer is yes, a 64-bit processor 
has more technology, a better design with more transistors, thus faster 
speeds are possible. This is currently where the true benefit of 
switching to a 64-bit processor lays, it has nothing to do with the 
memory address space, which is exactly that, just space for more complex 
computations.


Peter


Alexey Solofnenko 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.


- Alexey.

Caldarale, Charles R wrote:
  
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED] Subject: Re: 
Tomcat with 8 GB memory


I was under impression that GC does not scale linearly. That means 
one 8GB process will be slower than two 4GB processes.

  

Not true.  The time of a full GC using modern algorithms depends mostly
on the number and type of live objects, not the amount of heap space.
The number and type of live (reachable) objects stays relatively
constant for most application once the ramp-up period is over.
Consequently, running a single JVM with the largest heap you can fit in
the process space is the most efficient from a GC point of view.  (Of
course, there are plenty of other reasons not to put all your eggs in
one basket.)

 - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  


--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652 


If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Please visit http://www.albourne.com/email.html for
important additional terms relating to this e-mail. 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






  


--
Peter Stavrinides
Albourne Partners (Cyprus) Ltd
Tel: +357 22 750652 

If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. 




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat with 8 GB memory