Resin optimization (JVM, performance parameters, Apache integration)

1. Monitor Resin Parameters

1. Add the following segments to the resin. conf file:

1. <Servlet-mapping servlet-class = 'com. Caucho. servlets. resinstatusservlet '>
2. <URL-pattern>/resin-status </url-pattern>
3. <Init enable = "read"/>
4. </Servlet-mapping>

When you access http: // domain name/resin-status, you can monitor the performance of resin.

2. You can also use the resin-Admin Function. You need to add the following code in resin. conf:

 

1. <Web-app id = "/resin-admin" Root-directory = "$ {resin. Home}/PHP/admin">
2. <! --
3. -Administration application/resin-Admin
4. -
5. -Password is the MD5 hash of the password.
6. -Localhost is true to limit access to the localhost
7. -->
8. <Prologue>
9. <Resin: Set Var = "resin_admin_user" value = "admin"/>
10. <Resin: Set Var = "resin_admin_password" value = "123456"/>
11. <Resin: Set Var = "resin_admin_external" value = "false"/>
12. </Prologue>
13. </Web-app>

Enter http: // domain name/resin-admin and get a password:SetVar = "resin_admin_password" value = "123456"/> change the password to this password. Restart resin to log on to resin-Admin using the account and password to monitor the resin performance in more detail.

Ii. Apache performance monitoring

If resin is integrated with Apache, add the following lines to httpd. conf:

 

1. <Location/Server-status>
2. Sethandler server-status
3. Order deny, allow
4. Allow from 192.168.78.188
5. </Location>

Allow from is the IP address that can be accessed. After restart, access http: // domain name/Server-status to monitor Apache performance.

 

Iii. JVM parameters:

Typical JVM parameter configurations are as follows:

<! --
-The JVM arguments
-->
<JVM-Arg>-xmx1024m </JVM-Arg>
<JVM-Arg>-xmn1024m </JVM-Arg>
<JVM-Arg>-xss1m </JVM-Arg>
<JVM-Arg>-XX: permsize = 1024 m </JVM-Arg>
<JVM-Arg>-XX: maxpermsize = 1024 m </JVM-Arg>
<JVM-Arg>-xdebug </JVM-Arg>
<JVM-Arg>-DCOM. Sun. Management. jmxremote </JVM-Arg>
The reprinted description is as follows:

Resin startup parameters: Tuesday, January 1, May 06, 2008

 

1. command-line arguments)

-Install (Windows) install Resin as a service (but doesn't automatically start .)

-Install-as XXX (Windows) install Resin as a named Service (but doesn't utomatically start .)

-Remove (Windows) install Resin as a service (but doesn't automatically start .)

-Remove-as XXX (Windows) Remove resin as a named Service (but doesn't automatically start .)

2. JDK parameters (JDK arguments: configuration of httpd. Sh parameters)
<1>. File Location: $ {resin30}/bin/httpd. Sh

<2>. ARGs = '-J-server-xms200m-xmx1024m-xloggc :. /log/GC. log-XX: maxnewsize = 256 m-XX: maxpermsize = 256 m-djava. AWT. headless = true'
Parameter description:

(1) J-server-xms200m-xmx1024m, where-xms200m indicates the initial memory size at startup, and-xmx1024m indicates the maximum memory usage. (-Xmn100m optional)

(2)-XX: maxnewsize = 256 m-XX: maxpermsize = 256 M indicates the size of the permanent storage area (permgen space) of the memory. The full name of permgen space is permanent generation space, it refers to the permanent storage area of the memory outofmemoryerror: permgen space is regarded as memory overflow, and the solution must be to increase the memory. This part is used to store class and meta information. When the class is loaded, it is placed in the permgen space area, which is different from the heap area where the instance is stored, GC (garbage collection) does not clean the permgen space during the main program running.
Generally, values like-XX: permsize = 64 m-XX: maxnewsize = 256 m-XX: maxpermsize = m do not need to be set unless perm overflows. Set maxpermsize, after adding-server to the startup script, you do not need to set maxnewsize.

(3)-djava. AWT. Headless = true solves the problem that images of Linux/Unix verification codes cannot be displayed.

3. General JVM Parameters

Specifies the command line parameters passed to the Java virtual machine code that starts the application server process.

The following are optional command line parameters that can be entered in the "common JVM Parameters" field. If you enter multiple independent variables, enter a space between them.
Important: If this parameter indicates that it is only applicable to IBM developer kit, you cannot use this parameter for another JVM, such as Sun JDK or hp jdk.
-Xquickstart
You can use-xquickstart to perform initial compilation at an optimization level lower than the default mode. Then, based on the sample results, you can use the default method to re-compile the initial compilation level. Xquickstart is suitable for early applications with an average speed that is more important than long-run throughput. In some debugging schemes, test devices, and short-run tools, the startup time can be reduced by 15% to 20%.

-Xverify: None
If you want to skip the class verification phase during class loading, you can use-xverify: none. Using-xverify: none when the JIT compiler is enabled can shorten the startup time by 10-15%.

-Xnoclassgc
You can use-xnoclassgc to disable class garbage collection. This operation can improve the class reuse degree and slightly improve the performance. However, the cost is that you cannot collect resources owned by these classes. You can use the verbose: GC configuration settings (this setting will output garbage collection statistics) to monitor garbage collection. Checking these statistics will help you understand the balance between the generated resources and the amount of garbage collection necessary for the generated resources. However, if you repeatedly recycle the same group of classes in your workload, you should disable garbage collection. By default, garbage collection is enabled.

-Xgcthreads
Multiple garbage collection threads can be used at the same time, which is also called Parallel garbage collection. When you enter this value in the "common JVM Parameters" field, you also need to enter the number of processors on your machine, for example,-xgcthreadsn, where N is the number of processors. On nodes with N processors, the default number of threads is N. If your machine has multiple processors, you should use parallel garbage collection. This parameter is only valid for IBM developer kit.

-Xnocompactgc
You can use-xnocompactgc to disable heap compression, which is the most costly garbage collection operation. Avoid compression in IBM developer kit. If you disable heap compression, all related overhead is eliminated.

-Xinitsh
You can use-xinitsh to set the initial size of the heap of the Storage Class Object. Method definition and static fields are also stored with class objects. Although there is no upper limit on the System Heap size, you can set the initial size to avoid spending on the extended System Heap size involving calling the operating system memory manager. You can calculate the ideal initial System Heap size by understanding the number of classes (approximately 8,000 classes) installed in WebSphere Application Server and their average size. Understanding applications helps you calculate them. You can only use this parameter for IBM developer kit.

-Xgpolicy
You can use-xgpolicy to set a garbage collection policy. If the garbage collection policy (gcpolicy) is set to optavgpause, use the heap flag to track the application threads started from the stack before the heap. The pause of the garbage collector becomes unified, and the long pause is no longer obvious. The cost is reduced throughput because the thread may have to perform additional operations. The default recommended value is optthruput. -Xgcpolicy: [optthruput | optavgpause]. You can only use this parameter for IBM developer kit.

-Xx
Sun-based Java Development Kit (JDK) v1.4.2 provides the garbage collection function, which allows separation of memory pools to contain objects with different durations. Garbage collection cycles collect objects that are independent of other objects based on the validity period. With other parameters, you can set the size of the memory pool separately. To achieve better performance, you should set the size of the pool containing short-lived objects so that the survival time of objects in the pool does not exceed a garbage collection cycle. The size of the newly generated pool is determined by the newsize and maxnewsize parameters.

Objects that survive in the first garbage collection cycle are transferred to another pool. The size of the survivor pool is determined by the descrivorratio parameter. If garbage collection becomes a bottleneck, you can customize the pool settings. To monitor garbage collection statistics, use the object statistics in Tivoli performance viewer or verbose: GC configuration settings. Enter the following values:
-XX: newsize (Lower Bound)
-XX: maxnewsize (Upper Bound)
-XX: Required vorratio = newratiosize
The default value is newsize = 2 m maxnewsize = 32 m Running vorratio = 2. However, if the JVM heap size is greater than 1 GB, the value-XX: newsize = 640 M-XX: maxnewsize = 640 M-XX: Large vorratio = 16 should be used, or allocate 50% to 60% of the total heap size to the newly generated pool.

-Xminf
You can use-xminf to specify the minimum available heap size percentage. If the available space is lower than the specified quantity, the heap increases. In the reset mode enabled, this option specifies the minimum percentage of available space for the middleware and transient heap. This is a floating point number between 0 and 1. The default value is. 3 (30% ).

-Server |-Client
Based on the Java hotspot technology in Sun's Java Development Kit (JDK) v1.4.2, an adaptive JVM is introduced, which contains an algorithm used to optimize bytecode execution over time. JVM runs in two ways:-server and-client. If you use the default value-client mode, you will get a fast start time and a small amount of memory, but the performance will be low. If you have enough time to allow hotspot JVM to warm up by executing continuous byte code, you can use the-server method to improve performance. In most cases, the-server method should be used, which will keep the running time efficient. You can monitor the process size and server startup time to check the difference between-client and-server.

High load configuration of Resin

 

The number of 10x9 entries per day.

The number of 10 ** 8 requests.

10x7 per machine

3600*24 = 10 ** 5

Average number of requests processed: 10 ** 2 = 100.

When 500 threads are started: Java. Lang. outofmemoryerror: Unable to create new Native thread

Reference: http://hzlinux.blog.bokee.net/bloggermodule/blog_viewblog.do? Id = 219280

Http://forum.java.sun.com/thread.jspa? Threadid = 615505 & messageid = 4450486

 

When you create a Java thread, in addition to creating a thread object in JVM, you also need to create the corresponding "Thread" in the operating system; java1.4 each thread should use a K stack size by default, java uses 1 m.

Absurd but true:To create more threads you have to reduce the memory allocated to the JVM.

This formula gives a decent estimate for the number of threads you can create:
(Maxprocessmemory-jvmmemory-reservedosmemory)/(threadstacksize) = number of threads

For Java 1.5 I get the following results assuming that the OS reserves about 120 MB:
1.5 GB allocated to JVM: (2gb-1.5gb-120mb)/(1 MB) = ~ 380 threads
1.0 GB allocated to JVM: (2gb-1.0gb-120mb)/(1 MB) = ~ 880 threads

Ulimit-A shows that the current maximum stack size limit in the system is 10240 kb or KB. But isn't the actual stack size?

Ulimit-s 512 sets the stack size limit to 512 KB.

Reduce the heap size (-XMS-xmx) to free up some space for the stack size (-XSS ).

Performance Tuning of ResinHttp://www.caucho.com/resin-3.0/config/tuning.xtp)

Thread-MAX:

Each Servlet request is processed by a corresponding thread, so thread-Max determines the maximum number of concurrent requests that resin can process.

Keep-alives:

This interface is used to reuse connections between resin and HTTP server. One connection can process multiple requests.

<Keepalive-max> 500 </keepalive-max>
<Keepalive-Timeout> 120 s </keepalive-Timeout>

Request-Timeout[This parameter is not available in resin3, and an error occurs during restart ]:

Each connection is in the idle state, and there can be only a limited time before resin closes it. If no new request is sent from the client during the specified time, resin will close the TCP socket. This timeout prevents idle connections from over-using resin resources.

<Cluster>
<Client-live-time> 20 S </client-live-time>

<Srun Port = "6802" Read-Timeout = "30 s"/>
</Cluster>

Read-Timeout will close srun connections, client-live-time is the time the plugin will keep a connection open. read-Timeout must always be larger than client-live-time, otherwise the plugin will try to reuse a closed socket.

 

Thread-keepalive[This parameter is not available in resin3 ]:

Number of threads to be used in keepalive requests. when resin is used in combination with a Web server, Like Apache or IIS, resin will reuse the socket connection to that web server if possible. thread-keepalive specifies the number of theads that can be used in these keepalive connections.