[Performance Tuning] - Large number of threads/connections marked "keep alive"
by Ben Hsu
Ben Hsu [http://community.jboss.org/people/benhsu_at_bluefly] created the discussion
"Large number of threads/connections marked "keep alive""
To view the discussion, visit: http://community.jboss.org/message/587341#587341
--------------------------------------------------------------
Hello
We're seeing an issue where the performance of our application would degrade over time, to the point where its unresponsive. Based on what I see, I think it might be related to how we're configuring keep-alive, and I'm wondering where I can find more information about configuring keep-alive in JBoss.
The symptoms:
- The application's performance would degrade over the day
- eventually we will get a message saying "all 200 threads are busy, please increase the maximum thread count"
- at this point, doing a thread dump (using "kill -3") shows many threads in the following state:
<blockquote>
"TP-Processor200" daemon prio=1 tid=0x0000002b31e372c0 nid=0x651a runnable [0x000000005408e000..0x000000005408ec30]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
- locked <0x0000002b082abec0> (a java.io.BufferedInputStream)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:558)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
</blockquote>
- when I look at the "connection scoreboard" in the JBoss web console, I see 200 connections marked with a "K" for "keep alive", also these connections look like they've been around for a long time (around 7,000,000ms, which will be 2 hours), long after we've killed all the clientsd
Based on what I saw above and some googling, I'm thinking this might be related to how we're configuring keep alive. I haven't been able to go further than this, because I don't know much about JBoss configuration. Does anybody have any information about how keep alive is being configured in JBoss?
We are using JBoss version 4.0.5 GA
Thank you!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/587341#587341]
Start a new discussion in Performance Tuning at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 2 months
[EJB3] - EJB3 Session Bean Pool
by Robert Geisler
Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion
"EJB3 Session Bean Pool"
To view the discussion, visit: http://community.jboss.org/message/597611#597611
--------------------------------------------------------------
hello...
during the last few weeks we experienced some problems with session bean instantiation.
in the past we used default session bean pool, ThreadlocalPool. this pool implementation creates instances for every newly created thread, but these instances seem to never be destroyed, not even if the threads, they were created for, die.
so we tried StrictMaxPool pool implementation and set a maximum of 100.000. with this pool we see much less bean instances, because the pool creates them only if there are no free instances left. existing beans (released earlier) get reused later, allthough they are not destroyed until container/ server shuts down.
a simple scenario: in the morning 200 users log in and read their private messages. they all start working at 8 a.m. and they are using mostly the same services. every single user needs one bean instance for one request and because all users request concurrently, StrictMaxPool creates 200 instances. later the users have lunch, so no one fires request to the server, all beans (200!) are released and waiting in the pool. but because StrictMaxPool does not destroy beans, the 200 instances are kept in server vm/ heap all the day (until shutdown!).
we think this behaviour is a waste of resources! a pool should destroy instances if there a more instances in the pool than we want to reserve for further usage. because later the day our 200 users will almost never produce 200 concurrent requests again, we would like to configure the pool to just keep a maximum of 50 beans.
so my questions are:
1) why are instances not destroyed by StrictMaxPool? there is an idea of destroying instances in StrictMaxPool.release, but because pool.size will never be more than maxSize (an attemp to get one more bean always fails!), remove is never called!?
2) is there a pool implementation that destroys instances and just holds a configurable amount of beans? or do we have to implement it on our own (TolerantMinPool ; ))?
3) ?some more suggestions?
thanks in advance
robert
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/597611#597611]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 3 months