Analyzed the maximum memory of different versions of JVMs of several popular companies, and the results are as follows: Company JVM version maximum memory (megabytes) client maximum memory (megabytes) server SUN 1.5.x 1492 1520 SUN 1.5 .5(Linux) 2634 2660 SUN 1.4.2 1564 1564 SUN 1.4.2(Linux) 1900 1260 IBM 1.4.2(Linux) 2047 N/A BEA JRockit 1.5 (U3) 1909 1902 Unless otherwise stated, Otherwise, the JVM versions all run under the Windows operating system. What I want to illustrate through this table is that if your machine has too much memory, you can only improve the machine utilization by running a few more instances. For example, if you run Tomcat, you You can install several more Tomcats and create clusters, and so on. Heap and Non-heap memory According to the official statement: "The Java virtual machine has a heap. The heap is the runtime data area, and the memory of all class instances and arrays is allocated from here. The heap is in Java Created when the virtual machine starts. "Memory outside the heap in the JVM is called non-heap memory." It can be seen that the JVM mainly manages two types of memory: heap and non-heap. Simply put, the heap is the memory accessible to Java code and is reserved for developers; the non-heap is the memory reserved for the JVM itself, so the memory required for method area and JVM internal processing or optimization (such as JIT compiled code cache), every class structure (such as the runtime constant pool, field and method data), and the code for methods and constructors are all in off-heap memory. Heap memory allocation The initial memory allocated by the JVM is specified by -Xms, and the default is 1/64 of the physical memory; the maximum memory allocated by the JVM is specified by -Xmx, and the default is 1/4 of the physical memory. By default, when the free heap memory is less than 40%, the JVM will increase the heap until the maximum limit of -Xmx; when the free heap memory is greater than 70%, the JVM will reduce the heap until the minimum limit of -Xms. Therefore, the server generally sets -Xms and -Xmx to be equal to avoid adjusting the heap size after each GC. Non-heap memory allocation JVM uses -XX:PermSize to set the initial value of non-heap memory, the default is 1/64 of the physical memory; XX:MaxPermSize sets the maximum size of the non-heap memory, the default is 1/4 of the physical memory. JVM memory limit (maximum value) First of all, JVM memory is limited to the actual maximum physical memory (nonsense! Haha). Assuming that the physical memory is infinite, the maximum value of JVM memory has a lot to do with the operating system. To put it simply, although the controllable memory space of a 32-bit processor is 4GB, the specific operating system will set a limit. This limit is generally 2GB-3GB (generally speaking, it is 1.5G-2G under Windows systems and 1.5G-2G under Linux systems). 2G-3G), and there will be no restrictions on processors above 64bit. So the main reasons why the program cannot be started due to setting VM parameters are as follows: 1) The value of -Xms in the parameter is greater than -Xmx, or the value of -XX:PermSize is greater than -XX:MaxPermSize; 2) The value of -Xmx and The sum of -XX:MaxPermSize exceeds the maximum limit of JVM memory, such as the maximum memory limit of the current operating system, or actual physical memory, etc.
1. It depends on the situation of each application, such as the average daily request volume, the average memory size after fullgc, etc. 2. It is recommended that the maximum does not exceed 3/4 of the operating system memory
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Analyzed the maximum memory of different versions of JVMs of several popular companies, and the results are as follows:
Company JVM version maximum memory (megabytes) client maximum memory (megabytes) server
SUN 1.5.x 1492 1520
SUN 1.5 .5(Linux) 2634 2660
SUN 1.4.2 1564 1564
SUN 1.4.2(Linux) 1900 1260
IBM 1.4.2(Linux) 2047 N/A
BEA JRockit 1.5 (U3) 1909 1902
Unless otherwise stated, Otherwise, the JVM versions all run under the Windows operating system. What I want to illustrate through this table is that if your machine has too much memory, you can only improve the machine utilization by running a few more instances. For example, if you run Tomcat, you You can install several more Tomcats and create clusters, and so on.
Heap and Non-heap memory According to the official statement: "The Java virtual machine has a heap. The heap is the runtime data area, and the memory of all class instances and arrays is allocated from here. The heap is in Java Created when the virtual machine starts. "Memory outside the heap in the JVM is called non-heap memory." It can be seen that the JVM mainly manages two types of memory: heap and non-heap. Simply put, the heap is the memory accessible to Java code and is reserved for developers; the non-heap is the memory reserved for the JVM itself, so the memory required for method area and JVM internal processing or optimization (such as JIT compiled code cache), every class structure (such as the runtime constant pool, field and method data), and the code for methods and constructors are all in off-heap memory. Heap memory allocation The initial memory allocated by the JVM is specified by -Xms, and the default is 1/64 of the physical memory; the maximum memory allocated by the JVM is specified by -Xmx, and the default is 1/4 of the physical memory. By default, when the free heap memory is less than 40%, the JVM will increase the heap until the maximum limit of -Xmx; when the free heap memory is greater than 70%, the JVM will reduce the heap until the minimum limit of -Xms. Therefore, the server generally sets -Xms and -Xmx to be equal to avoid adjusting the heap size after each GC. Non-heap memory allocation JVM uses -XX:PermSize to set the initial value of non-heap memory, the default is 1/64 of the physical memory; XX:MaxPermSize sets the maximum size of the non-heap memory, the default is 1/4 of the physical memory. JVM memory limit (maximum value) First of all, JVM memory is limited to the actual maximum physical memory (nonsense! Haha). Assuming that the physical memory is infinite, the maximum value of JVM memory has a lot to do with the operating system. To put it simply, although the controllable memory space of a 32-bit processor is 4GB, the specific operating system will set a limit. This limit is generally 2GB-3GB (generally speaking, it is 1.5G-2G under Windows systems and 1.5G-2G under Linux systems). 2G-3G), and there will be no restrictions on processors above 64bit.
So the main reasons why the program cannot be started due to setting VM parameters are as follows:
1) The value of -Xms in the parameter is greater than -Xmx, or the value of -XX:PermSize is greater than -XX:MaxPermSize; 2) The value of -Xmx and The sum of -XX:MaxPermSize exceeds the maximum limit of JVM memory, such as the maximum memory limit of the current operating system, or actual physical memory, etc.
1. It depends on the situation of each application, such as the average daily request volume, the average memory size after fullgc, etc.
2. It is recommended that the maximum does not exceed 3/4 of the operating system memory