Tomcat modify the memory configuration

A configuration

Tomcat / conf / server.xml modify the configuration

Second, Parameter Description

maxIdleTime: The maximum idle time exceeds this idle time, and the number of threads is greater than minSpareThreads, will be recovered, a default value of one minute (60,000ms);
minSpareThreads: the minimum number of idle threads in all circumstances the number of threads surviving, even more than the maximum idle time, it will not be recovered, the default value of 4;
maxSpareThreads: maximum number of idle threads, active over within a maximum idle time (maxIdleTime), idle this time, when the idle time is greater than maxIdleTime were recovered, the small to survive, waiting to be schedule, the default value 50;
the maxThreads: maximum number of threads, concurrent requests is large, Tomcat to create the maximum number of threads to handle requests into the request queue exceeds the queue, the default value 200 is;
acceptCount to: when the maximum number of threads ( maxThreads), when used up, can be put request queuing number, this number exceeds the return connection refused (request was rejected), and is generally provided as maxThreads, but this needs to be weighed according to their specific application to access the actual peak and average The default value is 100;
Connection Timeout: the network connection timeout, set to 0 is assumed never time out, arranged such huge risks, as generally set 30000ms, default 60000ms.
Windows Tomcat allows each process maxThreads (maximum number of threads) 2000
Linux Tomcat allows each process maxThreads (maximum number of threads) 1000

Illustration of the principle of the thread pool

Consider the following three cases

Case 1: a request is received, then the number of threads does not reach the maxThreads start tomcat, tomcat will start a thread to handle this request.

Case 2: a request is received, then the number of threads has reached the maxThreads start tomcat, tomcat this request in a queue will wait idle threads.

Case 3: a request is received, then the number of threads has reached the maxThreads tomcat start, the number of requests in the queue wait reached acceptCount to this time tomcat directly rejects the request, return connection refused

How to configure maxThreads

Generally include an amount of operation of the server: 1 (primarily in consumption cpu), 2 waits (io, databases, etc.)

The first extreme case, if our operation is purely computational, then the system response time is the main limiting cpu computing power, this time maxThreads should try to set up a small, reducing the number of threads within the same time fighting for cpu, you can improve computational efficiency, improve the overall system capacity.

The second extreme case, if our operation is purely IO or database, then the main limiting response time becomes wait for external resources, this time maxThreads should try to make it big, so as to increase the number of requests processed simultaneously, thereby enhancing overall system processing power. In this case because the volume of requests processed simultaneously tomcat will be relatively large, so it is necessary to look at open file limit virtual machine memory settings and the tomcat of linux.

I encountered a problem during a test, maxThreads I set relatively large, such as 3000, when the number of threads services to a certain extent, usually early 2000, will dramatically increase the response time of a single request,

It is puzzling why around for answers to no avail, and finally I summarize the reasons may be the cpu consumes when the thread switching time increases as the number of threads increases,

cpu put most of the time used to switch directly on the more than 2,000 in this thread, of course, there is no cpu time to deal with our procedure.

It had previously been considered a simple multi-threaded = high efficiency. . In fact, multi-threading cpu itself does not improve efficiency, but too many threads will reduce the cpu efficiency.

When the cpu core count <number of threads, cpu will need to directly switch back and forth multiple threads to ensure that each thread will get cpu time, that is, we usually say that concurrent execution.

So maxThreads configuration is definitely not the bigger the better.

Real-world applications, our operations will include more than two types (computing, wait), so maxThreads configuration is not an optimal value, it must be configured according to specific circumstances.

The best approach is: on the basis of continuous testing, continuously adjust and optimize, to get the most reasonable configuration.

acceptCount configuration, I usually set up as big maxThreads, this value should be based primarily on the peak and the average access application configured to weigh.

Assuming that a smaller, faster ensure appropriate request accepted, but beyond the request may be rejected directly

If the set is large, there will be circumstances may request a lot of overtime, because the processing capability of our system is certain.

Tomcat modify the memory configuration

Guess you like