Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
This is one of most important tuning factor: the heap ratio. The heap ratio
specifies how the amount of the total heap will be partitioned between the
young and the tenured space. What happens if you have lots of long lived data
(cached data, collections ) ? maybe you're in this situation:
The problem here is that the long lived data overflows the tenured generation.
When a collection is needed the tenured generation is basically full of live data.
Much of the young generation is also filled with long lived data. The result was thata
minor collection could not be done successfully (there wasn't enough room in
the tenured generation for the anticipated promotions out of the young generation)
so a major collection was done.
The major collection worked fine, but the results again was that the tenured
generation was full of long lived data and there was long lived data in the young
generation. There was also free space in the young generation for more allocations,
but the next collection was again destined to be a major collection.
By decreasing the space in the young generation and putting that space into the
tenured generation (a value of NewRatio larger than the default value was chosen),
there was enough room in the tenured generation to hold all the long lived data and
also space to support minor collections. This particular application used lots of short
lived objects so after the fix mostly minor collections were done.
NewRatio is a flag that specifies the amount of the total heap that will be
partitioned into the young generation. It's the tenured-generation-size / young-
generation-size. For example, setting -XX:NewRatio=3 means that the ratio between
the young and tenured generation is 1:3
If you want a more precise control over the young generation : NewSize is the
initial size of the young generation,MaxNewSize will specify the maximum size of
the young generation
JBoss tuning tip 10: Monitor the free memory with monitors and snapshots
Each operating system sets default tuning parameters differently. For Windows
platforms, the default settings are usually sufficient. However, the UNIX and Linux
operating systems usually need to be tuned appropriately
/dev/tcp tcp_time_wait_interval
/dev/tcp tcp_conn_req_max_q
/dev/tcp tcp_conn_req_max_q0
/dev/tcp tcp_ip_abort_interval
/dev/tcp tcp_keepalive_interval
/dev/tcp tcp_rexmit_interval_initial
/dev/tcp tcp_rexmit_interval_max
/dev/tcp tcp_rexmit_interval_min
/dev/tcp tcp_smallest_anon_port
/dev/tcp tcp_xmit_hiwat
/dev/tcp tcp_recv_hiwat
/dev/ce instance
/dev/ce rx_intr_time
Tip: Use the netstat -s -P tcp command to view all available TCP parameters.
set rlim_fd_cur
set rlim_fd_max
set tcp:tcp_conn_hash_size (Solaris 8 and 9)
set ip:ipcl_conn_hash_size (Solaris 10)
set shmsys:shminfo_shmmax Note: This should only be set for machines that have
at least 4 GB RAM or higher.
set autoup
set tune_t_fsflushr
sysctl -w net.core.rmem_default=262144
(default socket receive buffer)
sysctl -w net.core.wmem_default=262144
(default socket send buffer)
sysctl -w net.core.rmem_max=262144
(max socket receive buffer)
sysctl -w net.core.wmem_max=262144
(max socket send buffer size)
Optimize MTU. The TCP maximum transfer unit is 1512 on the Internet. If you are
sending larger packets it's a good idea to increase MTU size in order to reduce
packet fragmentation (especially if you have a slow network)
$ cat /proc/meminfo
JBoss tuning tip 12: Lots of Requests ? check JBoss thread pool
1
<mbean code="org.jboss.util.threadpool.BasicThreadPool"
2 name="jboss.system:service=ThreadPool">
3 <attribute name="Name">JBoss System Threads</attribute>
4 <attribute name="ThreadGroupName">System Threads</attribute>
5 <attribute name="KeepAliveTime">60000</attribute>
6 <attribute name="MaximumPoolSize">10</attribute>
<attribute name="MaximumQueueSize">1000</attribute>
7 <attribute name="BlockingMode">run</attribute>
8 </mbean>
9
For most applications this defaults will just work well, however if you are running an
application with issues lots of requests to jboss (such as EJB invocations) then
monitor your thread pool. Open the Web Console and look for the
MBeanjboss.system:service=ThreadPool.
Start a monitor on the QueueSize parameter. Have you got a QueueSize which
reaches MaximumPoolSize ? then probably you need to set a higher
MaximumPoolSize pool size attribute
Watchout! Speak at first with your sysadmin and ensure that the CPU capacity
support the increase in threads.
Watchout! if your threads make use of JDBC connections you'll probably need to
increase also the JDBC connection pool accordingly. Also verify that your HTTP
connector is enabled to handle that amount of requests
JBoss supports connectors for http, https, and ajp. The configuration file is
server.xml and it's deployed in the root of JBoss web container (In JBoss 4.2.0 it's:
"JBOSS_HOME\server\default\deploy\jboss-web.deployer")
The underlying HTTP connector of JBoss needs to be fine tuned for production
settings. The important parameters are:
Open the web.xml in deploy/jboss-web.deployer/conf folder. Look for the jsp servlet
in the file and modify the following XML fragment as given below:
1
<init-param>
2 <param-name>development</param-name>
3 <param-value>false</param-value>
4 </init-param>
5 <init-param>
<param-name>checkInterval</param-name>
6
<param-value>300</param-value>
7 </init-param>
8
References:
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
http://people.redhat.com/alikins/system_tuning.html
http://community.jboss.org/wiki/JBossASTuningSliming
This Performance tuning tutorial is updated to the release 4.x of the application
server. If you want to learn all about JBoss 4.x-5.x-6.x Performance tuning, Optimal
data Persistence, Clustering tuning, Web application tuning and much more you
should not miss the JBoss Performance Tuning book.
Read more about the book here
JBoss uses RMI for EJB communication and by default creates a single thread for
every incoming request.
When the number of requests is very large this could be a bottleneck. However you
can switch from the standard jrmp service invoker to the pool invoker.
<invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
<invoker-mbean>jboss:service=invoker,type=pooled</invoker-mbean>
Notice you can even have a mixed environment: that is stateless invocation
managed by the pool and all others by jrmp.
If you want to change the default attributes of your pool then open jboss-
service.xml
1 <mbean code="org.jboss.invocation.pooled.server.PooledInvoker"
2 name="jboss:service=invoker,type=pooled">
3
<attribute name="NumAcceptThreads">1</attribute>
4 <attribute name="MaxPoolSize">300</attribute>
5 <attribute name="ClientMaxPoolSize">300</attribute>
6 <attribute name="SocketTimeout">60000</attribute>
7 <attribute name="ServerBindAddress">${jboss.bind.address}</attribute>
8 <attribute name="ServerBindPort">4445</attribute>
9 <attribute name="ClientConnectAddress">${jboss.bind.address}</attribute>
10 <attribute name="ClientConnectPort">0</attribute>
<attribute name="ClientRetryCount">1</attribute>
11
<attribute name="EnableTcpNoDelay">false</attribute>
12
</mbean>
13
There are two key attributes for the PooledInvoker in regards to how many threads
are used in processing requests. The first is the NumAcceptThreads attribute.
The value for this attribute will determine how many threads are created to listen
for incoming requests. These threads will be the ones that call the accept() method
of the server socket (which is a blocking call and will wait there till data is received
on the network interface for the server socket).
The MaxPoolSize is the other key factor: it's the size of the pool containing the
ServerThreads .
How can MaxPoolSize become a bottleneck ? if the accept thread can not get a
worker thread from the pool and the pool size has reached the MaxPoolSize value, it
will wait for one to become available (instead of creating a new one).
Tip 16: Have you got readonly Entity Beans ? tell it to JBoss
JBoss offers a way to handle this situation by defining either an entire EJB as being
"read-only" or simply as a subset of its methods. When accessing a read-only
method (or EJB), while JBoss still prevents concurrent access to the same bean
instance, the bean will not be enrolled in the transaction and will not be locked
during the whole transaction lifetime. Consequently, other transactions can directly
use it for their own work.
1
<enterprise-beans>
2 <entity>
3 <ejb-name>MyEntity</ejb-name>
4 <method-attributes>
5 <method>
6 <method-name>get*</method-name>
7 <read-only>true</read-only>
8 </method>
<method-attributes>
9
</entity>
10
</enterprise-beans>
11
Tip 18: Configure the EJB container to use cache, when possible.
If the EJB container has exclusive access to the persistent store, it doesnt need to
synchronize the in-memory bean state from the persistent store at the beginning of
each transaction.
So you could activate the so-called Commit-A option that caches entity bean state
between transactions. In order to activate this option :
1
<jboss>
2
<enterprise-beans>
3
4
<container-configurations>
5
<container-configuration extends=
6
"Standard CMP 2.x EntityBean">
7
<container-name>CMP 2.x and Cache</container-name>
8 <commit-option>A</commit-option>
9 </container-configuration>
10 </container-configurations>
11
12 <entity>
13 <ejb-name>MyEntity</ejb-name>
14 <configuration-name
<method-attributes>
16
<method>
17
<method-name>get*</method-name>
18
<read-only>true</read-only>
19
</method>
20
<method-attributes>
21
</entity>
22
</jboss>
23
Tip 19: Use Cache invalidation in a Cluster for Commit Option A
Commit option A can boost your Entity Bean but what happens when running in a
cluster ? in a cluster configuration more than one JBoss node will access the same
database. Furthermore, they will not only read data, but may also update the db
store.Consequently, we now have as many points of write access to the database as
we have JBoss instances in the cluster.
For these scenarios, JBoss incorporates a handy tool: the cache invalidation
framework. It provides automatic invalidation of cache entries in a single node or
across a cluster of JBoss instances. As soon as an entity bean is modified on a node,
an invalidation message is automatically sent to all related containers in the cluster
and the related entry is removed from the cache. The next time the data is required
by a node, it will not be found in cache, and will be reloaded from the database.
In order to activate it, add to your Entity Bean the cache-invalidation tag.
1 <entity>
2 <ejb-name>MyEntity</ejb-name>
<configuration-name>
3
Standard CMP 2.x with cache invalidation
4
</configuration-name>
5
<method-attributes>
6
<method>
7
<method-name>get*</method-name>
8
<read-only>true</read-only>
9
</method>
10
<method-attributes>
11 <cache-invalidation>True</cache-invalidation>
12 </entity>
13
1 <container-configuration>
3 <call-logging>false</call-logging>
4 <invoker-proxy-binding-name>entity-pooled-invoker</invoker-proxy-binding-name>
5 <sync-on-commit-only>true</sync-on-commit-only>
6 ....
</container-configuration>
7
XA Datasources jboss-xa-jdbc.rar
JSR-77 management/console-mgr.sar
1
<mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
2
name="jboss.management.local:j2eeType=J2EEDomain,name=Manager">
3
<attribute name="MainDeployer">jboss.system:service=MainDeployer</attribute>
4
<attribute name="SARDeployer">jboss.system:service=ServiceDeployer</attribute>
5 <attribute name="EARDeployer">jboss.j2ee:service=EARDeployer</attribute>
6 <attribute name="EJBDeployer">jboss.ejb:service=EJBDeployer</attribute>
7 <attribute name="RARDeployer">jboss.jca:service=RARDeployer</attribute>
8 <attribute name="CMDeployer">jboss.jca:service=ConnectionFactoryDeployer</attribute>
9 <attribute name="WARDeployer">jboss.web:service=WebServer</attribute>
10 <attribute name="CARDeployer">jboss.j2ee:service=ClientDeployer</attribute>
11 <attribute name="MailService">jboss:service=Mail</attribute>
<attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>
12
<attribute name="JNDIService">jboss:service=Naming</attribute>
13
<attribute name="JTAService">jboss:service=TransactionManager</attribute>
14
<attribute name="UserTransactionService">jboss:service=ClientUserTransaction</attribut
15
<attribute name="RMI_IIOPService">jboss:service=CorbaORB</attribute>
16
</mbean>
17
Wel not really anyway Log4j uses a valuable amount of time/CPU so you had better
remove unnecessary logs, for example :
Comment the following line in log4j.xml in order to remove logs on the Console:
1 <p class="ol-foreground"><root>
3 <appender-ref ref="FILE"></appender-ref>
4 </root>
6 </p>
Consider raising the log level to the highest level possible in production. Here only
error logs are written:
1 <p class="ol-foreground"><root>
4 <appender-ref ref="FILE"></appender-ref>
5 </root>
6 </p><p class="ol-foreground"></p>