> From: Ian H [mailto:[EMAIL PROTECTED] > Subject: Re: Error when increasing Tomcat's maximum memory pool > > - the maximum memory available for allocation for the pool will depend > on the amount of contiguous memory that's available to be allocated
It's the amount of contiguous virtual memory available, after Windows has scettered code segments and DLLs all over it. > - on a W2K box with 4GB of RAM, we will likely have, by default, 2GB > earmarked for the OS, and 2GB for applications (seriously cutting into > what would be contiguous and available for the pool) The amount of installed RAM has nothing to do with the amount of virtual space allocated to the OS and each process. If you have a large enough paging file and a lot of patience, you can run a Windows system with much less than 1 GB of RAM and still have 2 GB of virtual space for each process and 2 GB for the OS. (It would run like crap, of course.) > - on W2K Enterprise or Datacenter editions, you could opt to start > with the /3GB switch and shift the allocation to 1GB/3GB for os/apps, > respectively, increasing the likelihood of more contiguous space being > available for the heap Correct. But again, that's 3 GB per process, not total for all processes. > [Regarding the /3GB switch not being recommended on W2K Standard > Edition: does anyone have direct experience with this configuration > and Tomcat as relates to stability, etc.?] Sorry, I don't know if the standard W2K even looks for this option. The impact it has on the OS is less room for internal data structures; Tomcat won't know the difference. > - given the hypothetical scenario that more contiguous space has > mysteriously been achieved for allocation (via choosing a different > hardware architecture or what have you) -- does Tomcat 5.5 still have > the 2GB limit I've heard mentioned? The limit has nothing to do with Tomcat, but with the JVM. Some levels of 32-bit JVMs didn't handle address ranges of more than 2 GB due to sign-extension problems. I haven't checked to see if that problem has been fixed in Sun's current 32-bit JVM. It's not a problem in 64-bit JVMs, of course. > Are there any guidelines to go by regarding how much of a > tradeoff there will be for the extra burden related to garbage > collection with larger heaps, or is it a matter of "test and see"? You'll have to test and see to be sure. Typically, for a given workload, the total heap size has little effect on the time a single GC takes, but it does affect the frequency of GCs. - 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]
