Re: Tomcat with 8 GB memory
so now we have to identify if our application is 64bit compatible or 32bit compatible. would not this be a very difficult situation as far as porting to 64bit is concerned? Andrew Miehs wrote: 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] -- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11922831 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
On 31/07/2007, at 2:04 PM, Mohan2005 wrote: so now we have to identify if our application is 64bit compatible or 32bit compatible. If your application is only JAVA, then no porting is required. 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
On Fri, Jul 27, 2007 at 07:25:26PM -0400, Christopher Schultz wrote: The reverse is true. First of all, no home user ever bought an 8-bit machine. Um, ask the owner of an Apple ][ about that. Likewise my Synertek SYM-1 used an 8-bit 6502 processor, as did designs by Atari, Commodore, etc. Then there were a number of designs built around the Zilog Z80, by Radio Shack, Sinclair, and others. Intel's line never caught on beyond the industrial and hobbyist markets until the 8086, but there were plenty of others. CP/M's market was 8-bit machines. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgpA8kcMoJEn5.pgp Description: PGP signature
Re: Tomcat with 8 GB memory
I think what we're seeing here is the reason for the oft-heard, seldom-heeded advice that the only benchmark which means anything is *your application*. Once you see how the code you care about performs, *then* you can bum a few cycles here and there to tune it up. Generalities such as 64-bit machines are faster/slower really don't say much outside the context of a specific application. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgp78pRVntwp4.pgp Description: PGP signature
Re: Tomcat with 8 GB memory
There can be hidden dependencies on native code. For example, JDBC drivers (OCI, ...). Fortunately there are usually corresponding 64 bit libraries available - you just need to update PATH or LD_LIBRARY_PATH. - Alexey. Andrew Miehs wrote: On 31/07/2007, at 2:04 PM, Mohan2005 wrote: so now we have to identify if our application is 64bit compatible or 32bit compatible. If your application is only JAVA, then no porting is required. 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] -- 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
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
Apologies Ron this was supposed to be directed at Andrew Miehs! Peter Stavrinides wrote: 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 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
On 30/07/2007, at 8:02 AM, Peter Stavrinides wrote: Apologies Ron this was supposed to be directed at Andrew Miehs! Peter Stavrinides wrote: From your comments Ron you obviously didn't understand a thing I wrote, because you have just repeated me! Dear Peter, Obviously! :-) On 29/07/2007, at 2:34 PM, Peter Stavrinides wrote: 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 I was mainly referring to this sentence. It is NOT true to say that it has nothing to do with memory space. Some of our Java processes are running 12G RAM - this would not be possible with 32bit - at least not with Java. (Yes it could be done with multiple processes and some for of communication between them) Memory space is ONE of the factors - and to be honest the one that was more important for our application than the 15% speedup. Regards 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
Andrew, In theory yes you are right, but remember that a 64bit Integer can also be calculated by a 32bit processor, but only in two CPU cycles, this is where the theoretical advantage of the 64 bit architecture lies. However in reality introducing the 64bit processor also introduces a number of new hardware related problems (peak bandwidth, sustained bandwidth, access latency), which have to do with he amount of data that two components (i.e. the CPU and RAM) can exchange over a given period. The catch 22 is that with increased processing power, the latency problem is getting worse (a side-effect of faster CPU's is more bus cycles worth of delay for each memory access) Vendors are trying to compensate in various ways, for example widening the bus. So, a 64bit processor alone cannot speed up your application, the 12G RAM will help, but your actual bandwidth may not be, in real terms, too different from a 32bit system with far less RAM because of latency problems. 64bit hardware designs are improving... this is where the real promise lies. I hope this explanation is a bit clearer, lol Peter Andrew Miehs wrote: On 30/07/2007, at 8:02 AM, Peter Stavrinides wrote: Apologies Ron this was supposed to be directed at Andrew Miehs! Peter Stavrinides wrote: From your comments Ron you obviously didn't understand a thing I wrote, because you have just repeated me! Dear Peter, Obviously! :-) On 29/07/2007, at 2:34 PM, Peter Stavrinides wrote: 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 I was mainly referring to this sentence. It is NOT true to say that it has nothing to do with memory space. Some of our Java processes are running 12G RAM - this would not be possible with 32bit - at least not with Java. (Yes it could be done with multiple processes and some for of communication between them) Memory space is ONE of the factors - and to be honest the one that was more important for our application than the 15% speedup. Regards 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 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
| From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Pet/64/VIC owners who would beg to differ... - The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying 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
Yes... and I still have my old Tandy Color Computer :-). It was a good machine for it's time. --David Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Pet/64/VIC owners who would beg to differ... - The information contained in this message is confidential proprietary property of Nelnet, Inc. and its affiliated companies (Nelnet) and is intended for the recipient only. Any reproduction, forwarding, or copying without the express permission of Nelnet is strictly prohibited. If you have received this communication in error, please notify us immediately by replying 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
From: David Smith [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat with 8 GB memory Yes... and I still have my old Tandy Color Computer :-). My Model I TRS-80 still boots... slowly... - 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
Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Pet/64/VIC owners who would beg to differ... I used my Tandy-1000 for many years, until I sold it after buying my super fast 16MHz 80286 with 16MB of RAM. D - 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 David, David kerber wrote: Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Apologies, Tracy. I was thinking of Intel chips, since that was where this abysmal thread had been going. You're right. There were home users of 8-bit general-purpose microprocessors. I used my Tandy-1000 for many years, until I sold it after buying my super fast 16MHz 80286 with 16MB of RAM. The Tandy-1000 did not have an 8-bit microprocessor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrkZM9CaO5/Lv0PARAoY2AJ0etHOgjcxbu9vNg4Urjhsw5965UwCdFZ2d B8hgq1VBM4emfWenp7lTfDY= =jhAk -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
So,... if I have 100s of users planned to hit the same Essbase application via Tomcat (5.0.28), do I need a 64 bit machine? And for us dummies, how do we set the heap and/or other performance-oriented settings? Karel -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David kerber wrote: Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Apologies, Tracy. I was thinking of Intel chips, since that was where this abysmal thread had been going. You're right. There were home users of 8-bit general-purpose microprocessors. I used my Tandy-1000 for many years, until I sold it after buying my super fast 16MHz 80286 with 16MB of RAM. The Tandy-1000 did not have an 8-bit microprocessor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrkZM9CaO5/Lv0PARAoY2AJ0etHOgjcxbu9vNg4Urjhsw5965UwCdFZ2d B8hgq1VBM4emfWenp7lTfDY= =jhAk -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] - 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
Depends on what the users are doing when they hit your application. If the are storing lots of data in the session then you'll need enough ram to hold all the expected data. If they are uploading files, i would imagine that you will need to have enough ram to hold the uploaded file before you stream it to disk or database. Although Tomcat might be smart? and store the uploaded files to disk, the tomcat guru's will have an answer to this. Saying all that is the Essbase app an inhouse app or a 3rd party one, if its 3rd party one then maybe they can give you some min requirements. To set the virtual machines heap size you can uses the -Xms -Xmx params. Go here [1] for info on the vm. The bottom line is, you need to understand what your app is going to do to work out what hardware your going to need. [1] http://java.sun.com/javase/technologies/hotspot/index.jsp On 7/30/07, Karel V Sedlacek [EMAIL PROTECTED] wrote: So,... if I have 100s of users planned to hit the same Essbase application via Tomcat (5.0.28), do I need a 64 bit machine? And for us dummies, how do we set the heap and/or other performance-oriented settings? Karel -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David kerber wrote: Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Apologies, Tracy. I was thinking of Intel chips, since that was where this abysmal thread had been going. You're right. There were home users of 8-bit general-purpose microprocessors. I used my Tandy-1000 for many years, until I sold it after buying my super fast 16MHz 80286 with 16MB of RAM. The Tandy-1000 did not have an 8-bit microprocessor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrkZM9CaO5/Lv0PARAoY2AJ0etHOgjcxbu9vNg4Urjhsw5965UwCdFZ2d B8hgq1VBM4emfWenp7lTfDY= =jhAk -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] - 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
On 7/30/07, ben short [EMAIL PROTECTED] wrote: If they are uploading files, i would imagine that you will need to have enough ram to hold the uploaded file before you stream it to disk or database. Although Tomcat might be smart? and store the uploaded files to disk Nothing to do with Tomcat -- this is the application's responsibility. (Commons FileUpload is nicely configurable in this area, FWIW.) -- Hassan Schroeder [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
Thanks Ben. Depends on what the users are doing when they hit your application. If the are storing lots of data in the session then you'll need enough ram to hold all the expected data. If they are uploading files, i would imagine that you will need to have enough ram to hold the uploaded file before you stream it to disk or database. Although Tomcat might be smart? and store the uploaded files to disk, the tomcat guru's will have an answer to this. Saying all that is the Essbase app an inhouse app or a 3rd party one, if its 3rd party one then maybe they can give you some min requirements. To set the virtual machines heap size you can uses the -Xms -Xmx params. Go here [1] for info on the vm. The bottom line is, you need to understand what your app is going to do to work out what hardware your going to need. [1] http://java.sun.com/javase/technologies/hotspot/index.jsp On 7/30/07, Karel V Sedlacek [EMAIL PROTECTED] wrote: So,... if I have 100s of users planned to hit the same Essbase application via Tomcat (5.0.28), do I need a 64 bit machine? And for us dummies, how do we set the heap and/or other performance-oriented settings? Karel -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, David kerber wrote: Nelson, Tracy M. wrote: | From: Christopher Schultz [mailto:[EMAIL PROTECTED] | Sent: Friday, 27 July, 2007 18:25 | | First of all, no home user ever bought an 8-bit machine. Oh, I'll bet there are a ton of former Apple ][, TRS-80 and Commodore Apologies, Tracy. I was thinking of Intel chips, since that was where this abysmal thread had been going. You're right. There were home users of 8-bit general-purpose microprocessors. I used my Tandy-1000 for many years, until I sold it after buying my super fast 16MHz 80286 with 16MB of RAM. The Tandy-1000 did not have an 8-bit microprocessor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrkZM9CaO5/Lv0PARAoY2AJ0etHOgjcxbu9vNg4Urjhsw5965UwCdFZ2d B8hgq1VBM4emfWenp7lTfDY= =jhAk -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] - 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] - 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
Point taken,... thanks Hassan On 7/30/07, ben short [EMAIL PROTECTED] wrote: If they are uploading files, i would imagine that you will need to have enough ram to hold the uploaded file before you stream it to disk or database. Although Tomcat might be smart? and store the uploaded files to disk Nothing to do with Tomcat -- this is the application's responsibility. (Commons FileUpload is nicely configurable in this area, FWIW.) -- Hassan Schroeder [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] - 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
thanks for the clarifications. Peter Stavrinides wrote: 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] -- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11917676 Sent from the Tomcat - User mailing list archive at Nabble.com
Re: Tomcat with 8 GB memory
thanks for the clarifications. ronatartifact wrote: 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] -- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11917677 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
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
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
...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
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
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
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
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 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
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
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 http://trelony.cjb.net/ Pleasant Hill, CA (GMT-8 usually) smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat with 8 GB memory
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
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
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
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
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
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. Fundemental problem is that a process can only use 2GB no matter how much memory you have. Java VM only gets to see 2GB no matter how much physical RAM you have. Once you get serious about transactions, 64 bit cleans 32 bit. Your entire software stack has to be written to use the extra memory addressing. OS, JVM, Servlet Engine. If you run a 32 bit Linux at the bottom, you are screwed, If you run a 32bit Java Run-time, screwed again. This is likely the big reason why high volume applications run on Enterprise platforms rather than open source. It is not about the quality of the software; it is about the attention to performance and the extra care in making sure that the whole stack is 64 bit. The subject title of this topic is a bit misleading. It should be something like Tomcat with 2 GB on an 8GB machine Its all in the numbers. http://msdn2.microsoft.com/en-us/vstudio/aa700838.aspx Tests were all run on the same hardware (AMD) so you can get past the CPU speed issue. How do you compare speed on AMD versus Intel (same $$$, similar product number, same clock speed, same marketing hype)? Ron Peter Crowther wrote: 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] - 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: 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
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
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
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
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
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 http://trelony.cjb.net/ Pleasant Hill, CA (GMT-8 usually) smime.p7s Description: S/MIME Cryptographic Signature
Re: Tomcat with 8 GB memory
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
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: 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
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
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
I would discourage to use such machine! 8GB means you are using 64 bit machine which will be much slower than 32 bit machines. Big memory is useful ONLY if you have applications that can benefit big memory such as database systems. In Java, if you use lots of memory and create lots of objects, your Java applications will have periodic seisures! This is because of garbage collection will take significant time, if started. I would be happy with 1 ~ 2 GB 32bit machines! This could deliver much faster services. Regards. 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? -- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11806665 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
On 26/07/2007, at 10:57 AM, 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. Big memory is useful ONLY if you have applications that can benefit big memory such as database systems. In Java, if you use lots of memory and create lots of objects, your Java applications will have periodic seisures! This is because of garbage collection will take significant time, if started. Dear Joe - I have more than 1 or 2 of these machines (16GB RAM, 6GB for Tomcat). The Sun 64bit JVM 1.5 is about 15% faster than the 32bit for our application. (Running under Tomcat) I would be happy with 1 ~ 2 GB 32bit machines! This could deliver much faster services. Java eats memory... The more memory you have, the more you can cache and the less you need to annoy your backend. 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
Our 64 bit machines outperform our 32 bit machines like night and day using Tomcat 5, I can only imagine the difference with Tomcat 6... in any event there is no difference for Tomcat it depends entirely on the virtual machine. Big memory is useful ONLY if you have applications that can benefit big memory such as database systems. Actually it is allocated directly to the JVM so you can have 50 gig if you want with no performance penalty Andrew Miehs wrote: On 26/07/2007, at 10:57 AM, 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. Big memory is useful ONLY if you have applications that can benefit big memory such as database systems. In Java, if you use lots of memory and create lots of objects, your Java applications will have periodic seisures! This is because of garbage collection will take significant time, if started. Dear Joe - I have more than 1 or 2 of these machines (16GB RAM, 6GB for Tomcat). The Sun 64bit JVM 1.5 is about 15% faster than the 32bit for our application. (Running under Tomcat) I would be happy with 1 ~ 2 GB 32bit machines! This could deliver much faster services. Java eats memory... The more memory you have, the more you can cache and the less you need to annoy your backend. 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 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
From: Joe Nathan [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat with 8 GB memory 8GB means you are using 64 bit machine which will be much slower than 32 bit machines. Neither conclusion is true. We have 8 GB machines using 32-bit CPUs, and proper 64-bit systems (those that are not IA64 based) are pretty much always faster than IA32. In Java, if you use lots of memory and create lots of objects, your Java applications will have periodic seisures! This is because of garbage collection will take significant time, if started. The above is also not true. The time taken for a garbage collection (even a full one) is pretty much independent of the size of the heap; it is very dependent on the number of live objects in the heap, which tends to be relatively constant for any given application. - 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, 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? Even better: why would either outperform the other when you haven't said what you're doing? For instance, a 32-bit machine trying to run 64-bit operations is hideously slow. A 64-bit machine running 32-bit operations should be just as fast as its 32-bit cousin, since it's getting no advantage with those wasted 32 extra bits per integer. I can't think of a single reason why a 64-bit processor would perform worse than a comparable 32-bit processor running the same code. The advantage of a 64-bit processor is access to more (flat) memory and it can do bigger operations with less scratch work. With comparable hardware, I would expect a 64-bit JVM (on 64-bit HW) to perform identically to a 32-bit JVM (on 32-bit HW) when running the same application (assuming that no heavy mathematical calculations are being done that could benefit from 64-bit capability). Big memory is useful ONLY if you have applications that can benefit big memory such as database systems. In Java, if you use lots of memory and create lots of objects, your Java applications will have periodic [seizures]! Hm. I don't think JVMs have used stop-the-world GC for some time, now. This is because of garbage collection will take significant time, if started. Full GCs happen very rarely, unless you are abusing your heap. I would be happy with 1 ~ 2 GB 32bit machines! This could deliver much faster services. While a fleet of 2GB commodity boxes do have their advantages, you don't have to set up complicated load balancing if you've got one huge machine that can do everything ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGqO5W9CaO5/Lv0PARApZvAJ9IJzzysOWlNEM9nqZb7uProue7YwCgwegp B8rE+zmpCLU7zeqWIG8ctVQ= =PtaY -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
From: lightbulb432 [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat with 8 GB memory The last is at the following link, several performance graphs for Linux show a slight or sharp decrease in performance for a given Tomcat instance beyond a certain number of users! Why is this? http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/ index.html Read the text, don't just look at the pictures: In the next part of this report, we will find that tuning the JVM memory parameters resolve the performance slump that we saw in this round of testing They overloaded a toy machine (512 MB - get serious) and saw GC issues. Nothing to do with Tomcat, just with overrunning their setup. Running multiple instances of Tomcat (or any other Java application) means you have _less_ aggregate heap memory available than for a single instance. I suspect running with JRE 6 would avoid the slump even without tweaking the heap settings, but I don't have time to verify that. - 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
When I asked this question I had in mind a few potential downsides to one 8 GB Tomcat. One is memory leaks: if Tomcat starts to leak memory (not sure if this happens too often, if ever, but I'm speaking purely hypothetically) then you'd rather not want your single Tomcat to eat up all the memory. If you had two Tomcat instances running the exact same application, then the memory leak is only affecting up to 4 GB? The other is high-availability - if you have a huge 8 GB box and it's because you decide not to have 4 x 2 GB smaller boxes, then you definitely cannot get high-availability against hardware issues - but say you're pushing out an upgrade to the application (i.e. the WAR file). If you have two Tomcats, couldn't you bring one down while the other continues to serve requests, push out the upgrade, bring it back up, then do the same with the other application? With only one instance, you must have downtime right? The last is at the following link, several performance graphs for Linux show a slight or sharp decrease in performance for a given Tomcat instance beyond a certain number of users! Why is this? Wouldn't these diminishing returns, if true, severly cripple one 8 GB instance serving 2*n users compared to two 4 GB instances serving only n users? http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/index.html Christopher Schultz-2 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] -- View this message in context: http://www.nabble.com/Tomcat-with-8-GB-memory-tf4149367.html#a11817605 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lightbulb, lightbulb432 wrote: When I asked this question I had in mind a few potential downsides to one 8 GB Tomcat. One is memory leaks: if Tomcat starts to leak memory (not sure if this happens too often, if ever, but I'm speaking purely hypothetically) then you'd rather not want your single Tomcat to eat up all the memory. If you had two Tomcat instances running the exact same application, then the memory leak is only affecting up to 4 GB? Well, if you have them properly load-balanced, then they'll both run out of memory at roughly the same time, right? The other is high-availability - if you have a huge 8 GB box and it's because you decide not to have 4 x 2 GB smaller boxes, then you definitely cannot get high-availability against hardware issues - but say you're pushing out an upgrade to the application (i.e. the WAR file). If you have two Tomcats, couldn't you bring one down while the other continues to serve requests, push out the upgrade, bring it back up, then do the same with the other application? With only one instance, you must have downtime right? True. You only asked about performance. In terms of performance, fewer moving parts is always better. Distribution helps solve other problems like geographical load-balancing to avoid network bottlenecks, improve availability (the more servers you have, the more likely one of them is to be in service), and facilitate roll-outs (upgrade one at a time). I generally find that the database upgrade is the thing that kills you, and that you need to have at least /some/ total down time to get everything in sync... re-deploying an application (upgrading) takes much less time than changes to your database). The last is at the following link, several performance graphs for Linux show a slight or sharp decrease in performance for a given Tomcat instance beyond a certain number of users! Why is this? Wouldn't these diminishing returns, if true, severely cripple one 8 GB instance serving 2*n users compared to two 4 GB instances serving only n users? http://www.webperformanceinc.com/library/reports/windows_vs_linux_part1/index.html That's a good question. Having only looked at the graph and not read the article in detail (or at all, really), I can only imagine that Linux and Windows have different strategies of dealing with incoming connections that the server software refuses to accept them. Perhaps Linux maintains a larger queue of incoming connections than Windows does, resulting in more successful connections, but slower response time for them. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGqQXO9CaO5/Lv0PARApehAKCyF5A1DtOR7t2nPlgLBQVEGQgjLACgv24j ariI7RtyV/5qedgyWaoFt9A= =lBfZ -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 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]
RE: Tomcat with 8 GB memory
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: Tomcat with 8 GB memory Why would a 64-bit machine run slower than a 32-bit machine? Try an IA64 - the sooner we forget about those the better. 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. - 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]
