Artur wrote:
Hello,
We have environment with Apache (2.2.0) + Tomcat (5.5.17) connected via
mod_jk (1.2.18). Further tomcat makes some queries to databese through
Tuxedo services (BEA).
Everything works fine until heavy load when something stops responding
(Service not available).
We think it is tomcat or mod_jk. It occures when "Max busy connections" on
mod_jk status manager shows about 200. Mod_jk is in error status then.
Understanding this situation would be helpful to decide, if adding
another tomcat really helps (problem=database => more tomcats don't help
etc.).
So we decided to use mod_jk load balancing feature and we installed another
instance of tomcat (on the same machine).
Now service is available even under heavy load but we are losing sessions.
What do you mean by "losing sessions"? I expect you mean users work in a
session and then they send a request and get a response indicating, that
the requested session has not been found?
If so:
- does it happen in times, when you get errors in the mod_jk-log? Does
it happen at all times, or do you have peaks at special times?
Stickyness sends users to the correct node, except when the node is not
reachable (error, stopped). In this case users will be sent to one of
the remaining nodes and - of course - without session replication their
session will not be there. Session repllication means to establish a
tomcat clusster, something you need to carefully test and that might
force changes in your app.
- if it happens even when there's no other problem at the same time:
make session IDs trackable. Either your app uses URL rewriting, then
your session ID is part of every request and logged in the apache access
log. Or you use Cookies, then add logging of incoming header "Cookie" to
your mod_log_config LogFormat. If you also add outgoing header
"Set-Cookie" you are able to follow the sessions, and you can decide, if
the users really send the correct session ID. Sometimes what you may
find is: the previous request produced an error in the app, which then
decided to invalidate the session.
You can also add a request log to mod_jk, that logs, which worker has
beend chosen for every request. That way you do not rely on your user
feedback, but can measure the problem yourself (how many users/sessions,
what time of day etc.).
Of course sticky_session is set to "true".
Below I paste our config files. Please help if you only can.
Best regards
Artur
###Jk status for one day:
Name Type jvmRoute Host Addr Stat D F M
V Acc Err Wr Rd Busy Max RR Cd
worker2 ajp13 worker2 localhost:8009 127.0.0.1:8009 OK 0 1
1 2144 824825 512
480M 5.8G 6 138 worker3
worker3 is in the original output and has iónly been removed by your
copy&paste?
What was happening, when you got these 2144 Errors? The time stamps
should be available from the mod_jk log.
###httpd.mpm section:
# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
StartServers 5
MaxClients 448
MinSpareThreads 5
MaxSpareThreads 25
ThreadsPerChild 7
MaxRequestsPerChild 0
</IfModule>
Interesting, very few ThreadsPerChild. Not really a problem, but I
wonder if this is efficient.
###workers.properties:
# Define 3 workers, 2 real workers using ajp13 and the last one being a
loadbalancing worker
worker.list=worker1,jkstatus
# Set properties for worker2 (ajp13)
worker.worker2.type=ajp13
worker.worker2.host=localhost
worker.worker2.port=8009
worker.worker2.lbfactor=1
worker.worker2.connection_pool_size=7
This should be set top the same value as ThreadsPerChild by mod_jk
automatically.
worker.worker2.connection_pool_timeout=300
worker.worker2.socket_timeout=60
Think about using connect_timeout and prepost_timeout. Maybe also set
recovery_options to 3.
# Set properties for worker4 (lb) which use worker1 and worker2
worker.worker3.type=ajp13
worker.worker3.host=localhost
worker.worker3.port=8019
worker.worker3.lbfactor=1
worker.worker3.connection_pool_size=7
worker.worker3.connection_pool_timeout=300
worker.worker3.socket_timeout=60
# Define a 'jkstatus' worker using status
worker.jkstatus.type=status
worker.worker1.type=lb
worker.worker1.sticky_session=true
worker.worker1.method=R
worker.worker1.balance_workers=worker2,worker3
###server1.xml - connector section:
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
/>
<Engine name="Catalina" defaultHost="localhost" jvmRoute="worker2">
###server2.xml - connector section
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8019"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3"
/>
<Engine name="Catalina" defaultHost="localhost" jvmRoute="worker3">
regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
