Shulou(Shulou.com)06/02 Report--

Tomcat virtual path

-

Tomcat memory parameters

1. The meaning of the parameter

-vmargs-Xms128M-Xmx512M-XX:PermSize=64M-XX:MaxPermSize=128M

-vmargs specification is followed by parameters of VM, so what follows is actually parameters of JVM.

-the heap memory initially allocated by Xms128m JVM

-Xmx512m JVM maximum allowed allocation of heap memory, allocated on demand

-XX:PermSize=64M JVM's initial allocation of non-heap memory

-the maximum amount of non-heap memory allowed to be allocated by XX:MaxPermSize=128M JVM, allocated on demand

Let's first take a look at the mechanism of JVM memory management, and then explain what each parameter represents.

1) Heap and Non-heap memory

Officially, "the Java virtual machine has a heap, which is the runtime data area from which all class instances and arrays of memory are allocated. The heap is created when the Java virtual machine starts."memory outside the heap in JVM is called non-heap memory (Non-heap memory).

You can see that JVM manages two main types of memory: heap and non-heap. To put it simply, heap is the memory accessible by Java code, which is reserved for developers; non-heap is reserved for JVM's own use.

So the method area, the memory required for JVM internal processing or optimization (such as JIT compiled code cache), each class structure (such as runtime time pools, fields and method data), and the code for methods and constructors are all in non-heap memory.

Heap memory allocation

The heap memory initially allocated by the JVM is specified by-Xms. By default, the maximum allocated heap memory of the JVM is specified by-Xmx, and the default is 1 bank 4 of the physical memory. When the default free heap memory is less than 40%, JVM increases the maximum limit of the heap up to-Xmx

When the free heap memory is greater than 70%, JVM reduces the minimum limit of the heap up to-Xms. So servers generally set-Xms and-Xmx equal to avoid resizing the heap after each GC.

Note: if-Xmx is not specified or the specified value is too small, the application may cause a java.lang.OutOfMemory error. This error comes from JVM, not Throwable, and cannot be captured by try...catch.

Non-heap memory allocation

JVM uses-XX:PermSize to set the initial value of non-heap memory, which defaults to 1x64 of physical memory, and XX:MaxPermSize sets the maximum size of non-heap memory, which defaults to 1x4 of physical memory. (another thing to say: the MaxPermSize default is related to the-server-client option

The default MaxPermSize is 64m under the-server option, and the default MaxPermSize is 32m under the MaxPermSize option. I don't have an experiment on this. )

The full name of PermGen space in the above error message is Permanent Generation space, which refers to the permanent storage area of memory. It is not clear whether PermGen space belongs to non-heap memory or just non-heap memory, but at least it belongs to.

The XX:MaxPermSize setting is too small to cause java.lang.OutOfMemoryError: PermGen space is the memory gain.

Tell me why memory benefits from:

(1) this part of the memory is used to store the information of Class and Meta. When Class is Load, it is put into the PermGen space area, which is different from the Heap area where Instance is stored.

(2) GC (Garbage Collection) does not clean up PermGen space during the run time of the main program, so if your APP can LOAD a lot of CLASS, PermGen space errors are likely to occur.

This kind of error is common when the web server pre compile JSP.

2) JVM memory limit (maximum)

First of all, JVM memory is limited to the actual maximum physical memory. 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, 32-bit processors have 4GB in their controllable memory space, but there is a limit to the specific operating system.

This limit is generally 2GB-3GB (generally speaking, it is 1.5G in Windows systems and 2G-3G in Linux systems), but there is no limit to processors above 64bit.

two。 Why do some machines start when I set-Xmx and-XX:MaxPermSize to 512m after Eclipse is set to 512m, while others can't?

Through the introduction to JVM memory management above, we have learned that JVM memory consists of two types: heap memory and non-heap memory, and the maximum JVM memory first depends on the actual physical memory and the operating system. Therefore, setting the VM parameter causes the program to fail to start mainly for the following reasons:

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 sum of the value of-Xmx and-XX:MaxPermSize exceeds the maximum JVM memory limit, such as the current operating system maximum memory limit, or the actual physical memory, and so on. When it comes to actual physical memory, what needs to be explained here is that

If your memory is 1024MB, but what is used in the actual system can not be 1024MB, because some of it is occupied by hardware.

3. Why did not write the above parameters to the eclipse.ini file Eclipse to perform the corresponding settings?

So why is the same parameter valid in the shortcut or command line but not in the eclipse.ini file? This is because we did not follow the rules for setting up eclipse.ini files:

The parameter is in the form of "item value". Those with spaces in the middle need to wrap the line, and those with spaces in the value need to be enclosed in double quotation marks. For example, we use the-vm C:/Java/jre1.6.0/bin/javaw.exe parameter to set the virtual machine

In the eclipse.ini file, write something like this:

-vm

C:/Java/jre1.6.0/bin/javaw.exe

-vmargs

-Xms128M

-Xmx512M

-XX:PermSize=64M

-XX:MaxPermSize=128M

The actual running result can be viewed through the "Configuration Details" button in the "Help"-"About Eclipse SDK" window in Eclipse.

It is also important to note that the contents of the eclipse.ini file included in the Eclipse package are as follows:

-showsplash

Org.eclipse.platform

-- launcher.XXMaxPermSize

256m

-vmargs

-Xms40m

-Xmx256m

The meaning of-launcher.XXMaxPermSize (note the first two connecting lines) is basically the same as the-XX:MaxPermSize parameter. I think the only difference is that the former is the parameter set when eclipse.exe starts.

The latter is a parameter in the JVM used by eclipse. In fact, setting one of the two is fine, so here you can comment out-launcher.XXMaxPermSize and the next line with #.

4. Other startup parameters. If you have a dual-core CPU, you might want to try this parameter:

-XX:+UseParallelGC

So that GC can be executed faster. (just a new parameter for GC in JDK 5)

Add:

If you use a large number of third-party jar under your WEB APP, its size exceeds the default size of the server jvm, then there will be a memory benefit problem.

Solution: set the MaxPermSize size

You can select the appropriate server in myelipse, such as tomcat5, and expand the JDK sub-item page to increase the JVM parameter settings started by the server:

-Xms128m

-Xmx256m

-XX:PermSize=128M

-XX:MaxNewSize=256m

-XX:MaxPermSize=256m

Or manually set the MaxPermSize size, such as tomcat

Modify TOMCAT_HOME/bin/catalina.bat by adding the following line above echo "Using CATALINA_BASE: $CATALINA_BASE":

JAVA_OPTS= "- server-XX:PermSize=64M-XX:MaxPermSize=128m

-

Tomcat thread pool configuration (optimized is the following result)

Important parameters description:

Number of concurrent requests processed by Tomcat = maxThreads + acceptCount

Protocol: enables APR connection mode to improve asynchronous IO processing performance. For more information on enabling configuration, please see "enable Tomcat APR operation mode to optimize concurrency performance"

MaxThreads: the maximum number of requests that can be accepted. Default is 200.

MinSpareThreads: minimum number of standby threads. Default initialization. Default is 25.

MaxSpareThreads: maximum number of standby threads. Once a thread is created beyond this value, Tomcat will shut down socket threads that are no longer needed.

AcceptCount: the request queue waiting to be processed. The default is 100, which exceeds the queue length. The server rejects the client request and returns 403 directly.

MaxIdleTime: if a thread is not active within 30 seconds, it is terminated and removed from the thread pool. Unless the number of thread pools is less than or equal to the number of minSpareThreads The default value is 1 minute

EnableLookups: if it is true, calling request.getRemoteHost will perform DNS reverse check and reverse resolution of the domain name or host corresponding to IP, which is inefficient. It is recommended to set it to false.

The meanings of the last two parameters are as follows:

The maximum number of threads started by maxThreads:tomcat, that is, the number of tasks processed at the same time. The default value is 200.

AcceptCount: when the number of threads started by tomcat reaches the maximum, the number of queued requests accepted. The default is 100.

How these two values work, look at the following three situations

Case 1: accept a request and the number of threads started by tomcat does not reach maxThreads,tomcat will start a thread to process the request.

Case 2: accept a request when the number of threads started by tomcat has reached maxThreads,tomcat. The request will be placed in a waiting queue for idle threads.

Case 3: accept a request, when the number of threads started by tomcat has reached maxThreads, and the number of requests in the waiting queue has also reached acceptCount, tomcat will directly reject the request and return connection refused

How to configure maxThreads

General server operations include quantity aspects: 1 computing (mainly consuming cpu), 2 waiting (io, database, etc.)

In the first extreme case, if our operation is pure computing, then the main limitation of the system response time is the computing power of cpu. At this time, maxThreads should be set as small as possible to reduce the number of threads competing for cpu at the same time, which can improve computational efficiency and improve the overall processing capacity of the system.

In the second extreme case, if our operation is purely IO or database, then the main limit of response time is to wait for external resources, and the maxThreads should be set as large as possible, so as to increase the number of requests processed at the same time, and thus improve the processing capacity of the system as a whole. In this case, because the number of requests processed by tomcat at the same time will be relatively large, you need to pay attention to the virtual machine memory settings of tomcat and the open file limits of linux.

I encountered a problem when I was testing. The maxThreads I set is relatively large, such as 3000. When the number of threads in the service is large to a certain extent, usually just over 2000, the response time of a single request will increase sharply.

It is hard to understand why it is futile to look for answers everywhere. In the end, I may sum up that the time consumed by cpu in thread switching is increasing as the number of threads increases.

Cpu spends most of his time switching directly between these 2000 threads, and of course cpu doesn't have time to deal with our program.

In the past, it was simply thought that multithreading = high efficiency. In fact, multithreading itself can not improve the efficiency of cpu, too many threads will reduce the efficiency of cpu.

When the number of cpu cores & 1 | / usr/sbin/cronolog / home/online/log/openapiroute/catalina.%Y-%m-%d.out > > / dev/null &

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.