You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Artur Różycki <ar...@upi.pl> on 2007/04/12 11:28:02 UTC
Mod_jk and "Kernel Panic - not syncing: Attempting to free lock on active lock list"
Hello,
We are running Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T) as
an Web server with Apache (2.2.4 compiled from sources) connected through
mod_jk (1.2.21 compiled from sources) to tomcat server(5.5.17). Everything
is installed on IBM x346 with 3GB of RAM and Xeon 3Ghz CPU. The kernel is
2.6.9-42.0.10.ELsmp from rpm package. After upgrading from mod_jk 1.2.18 to
mod_jk 1.2.21, during heavy load in work hours sometimes server hangs with
message: "Kernel Panic - not syncing: Attempting to free lock on active lock
list" and it stops responding to anything. After restarting it can work for
several hours without any problem but suddenly it hangs. We suspect that new
mod_jk is the reason. Now we are back on mod_jk 1.2.18 and problem doesn't
occur during last 30 hours.
This problem occures on several identical machines (IBM x346), so it's not a
hardware dependent.
Below is our configuration, maybe you have any suggestions to change
something for better performance.
####### worker.properties ########
worker.list=worker4,jkstatus
worker.worker2.type=ajp13
worker.worker2.host=localhost
worker.worker2.port=8009
worker.worker2.lbfactor=1
worker.worker2.socket_timeout=60
worker.worker2.connection_pool_timeout=300
worker.worker3.type=ajp13
worker.worker3.host=localhost
worker.worker3.port=8109
worker.worker3.lbfactor=1
worker.worker3.socket_timeout=60
worker.worker3.connection_pool_timeout=300
worker.jkstatus.type=status
worker.worker4.type=lb
worker.worker4.sticky_session=true
worker.worker4.balance_workers=worker2,worker3
####### worker.properties ########
####### httpd.conf #########
# worker MPM
<IfModule mpm_worker_module>
ServerLimit 64
StartServers 20
MaxClients 960
MinSpareThreads 20
MaxSpareThreads 100
ThreadsPerChild 15
MaxRequestsPerChild 30000
</IfModule>
####### httpd.conf #########
######## server.xml ###########
<Connector
port="8009"
redirectPort="8433"
secure="true"
connectionTimeout="0"
threadPriority="25"
connectionUploadTimeout="0"
connectionLinger="0"
maxSpareThreads="100"
maxThreads="500"
maxKeepAliveRequests="250"
disableUploadTimeout="false"
uRIEncoding="ISO-8859-2"
tcpNoDelay="false"
minSpareThreads="4"
acceptCount="60000"
protocol="AJP/1.3">
</Connector>
######## server.xml ###########
Thanks in advance for any help.
Best regards
Artur
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Mod_jk and "Kernel Panic - not syncing: Attempting to free lock
on active lock list"
Posted by Rainer Jung <ra...@kippdata.de>.
Artur wrote:
> Hello after the weekend,
>
> Does it mean that mod_jk 1.2.18 is not using flock() function at all ?
> With 1.2.18 there is no kernel panic problem.
> I have written to RedHat support to tell them that this flock() function
> could be buggy.
It does use flock(), but maybe with another use pattern. I'm not sure
about that.
> Do you know when 1.2.22 version is goint to be released ?
Most likely today or tomorrow.
> And another question. I have set logging for mod_jk to error level, but it
> logs every request and response time, shoudn't only errors be logged ?
Sounds like you are using JkRequestLogFormat, which will additionally
(unconditionally) log every request to the mod_jk log file.
> Normally response time is sth like 0.0500 or 0.0900 but sometimes it is
> 10.2345 or 15.2543 or even 90.0456. What can take so much time ?
Add %D to your tomcat access log and check, if the request als take that
long on tomcat (which is very likely). If yes, you need to investigate
the webapp/tomcat/jvm side.
>
> Regards
> Artur
>
>
> Mladen Turk wrote:
>> Artur Różycki wrote:
>>> Hello,
>>>
>>> We are running Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T)
>>> as an Web server with Apache (2.2.4 compiled from sources) connected
>>> through mod_jk (1.2.21 compiled from sources) to tomcat server(5.5.17).
>> This is a kernel bug related to flock
>> With 1.2.22 we are using fcntl for locking, so it won't be observed.
>>
>>
>>
>> Regards,
>> Mladen.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Mod_jk and "Kernel Panic - not syncing: Attempting to free lock
on active lock list"
Posted by Artur <ar...@upi.pl>.
Hello after the weekend,
Does it mean that mod_jk 1.2.18 is not using flock() function at all ?
With 1.2.18 there is no kernel panic problem.
I have written to RedHat support to tell them that this flock() function
could be buggy.
Do you know when 1.2.22 version is goint to be released ?
And another question. I have set logging for mod_jk to error level, but it
logs every request and response time, shoudn't only errors be logged ?
Normally response time is sth like 0.0500 or 0.0900 but sometimes it is
10.2345 or 15.2543 or even 90.0456. What can take so much time ?
Regards
Artur
Mladen Turk wrote:
>
> Artur Różycki wrote:
>> Hello,
>>
>> We are running Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T)
>> as an Web server with Apache (2.2.4 compiled from sources) connected
>> through mod_jk (1.2.21 compiled from sources) to tomcat server(5.5.17).
>
> This is a kernel bug related to flock
> With 1.2.22 we are using fcntl for locking, so it won't be observed.
>
>
>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Mod_jk-and-%22Kernel-Panic---not-syncing%3A-Attempting-to-free-lock-on-active-lock-list%22-tf3564396.html#a10030362
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Mod_jk and "Kernel Panic - not syncing: Attempting to free lock
on active lock list"
Posted by Mladen Turk <ml...@gmail.com>.
Artur Różycki wrote:
> Hello,
>
> We are running Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T)
> as an Web server with Apache (2.2.4 compiled from sources) connected
> through mod_jk (1.2.21 compiled from sources) to tomcat server(5.5.17).
This is a kernel bug related to flock
With 1.2.22 we are using fcntl for locking, so it won't be observed.
Regards,
Mladen.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Mod_jk and "Kernel Panic - not syncing: Attempting to free lock
on active lock list"
Posted by Rainer Jung <ra...@kippdata.de>.
Are you able to produce a stack dump (from a core) of the httpd process,
which is responsible?
Artur Różycki wrote:
> Hello,
>
> We are running Red Hat Enterprise Linux ES (v. 4 for AMD64/Intel EM64T)
> as an Web server with Apache (2.2.4 compiled from sources) connected
> through mod_jk (1.2.21 compiled from sources) to tomcat server(5.5.17).
> Everything is installed on IBM x346 with 3GB of RAM and Xeon 3Ghz CPU.
> The kernel is 2.6.9-42.0.10.ELsmp from rpm package. After upgrading from
> mod_jk 1.2.18 to mod_jk 1.2.21, during heavy load in work hours
> sometimes server hangs with message: "Kernel Panic - not syncing:
> Attempting to free lock on active lock list" and it stops responding to
> anything. After restarting it can work for several hours without any
> problem but suddenly it hangs. We suspect that new mod_jk is the reason.
> Now we are back on mod_jk 1.2.18 and problem doesn't occur during last
> 30 hours.
>
> This problem occures on several identical machines (IBM x346), so it's
> not a hardware dependent.
> Below is our configuration, maybe you have any suggestions to change
> something for better performance.
>
> ####### worker.properties ########
> worker.list=worker4,jkstatus
> worker.worker2.type=ajp13
> worker.worker2.host=localhost
> worker.worker2.port=8009
> worker.worker2.lbfactor=1
> worker.worker2.socket_timeout=60
> worker.worker2.connection_pool_timeout=300
> worker.worker3.type=ajp13
> worker.worker3.host=localhost
> worker.worker3.port=8109
> worker.worker3.lbfactor=1
> worker.worker3.socket_timeout=60
> worker.worker3.connection_pool_timeout=300
> worker.jkstatus.type=status
> worker.worker4.type=lb
> worker.worker4.sticky_session=true
> worker.worker4.balance_workers=worker2,worker3
> ####### worker.properties ########
>
> ####### httpd.conf #########
> # worker MPM
> <IfModule mpm_worker_module>
> ServerLimit 64
> StartServers 20
> MaxClients 960
> MinSpareThreads 20
> MaxSpareThreads 100
> ThreadsPerChild 15
> MaxRequestsPerChild 30000
> </IfModule>
> ####### httpd.conf #########
>
> ######## server.xml ###########
> <Connector
> port="8009"
> redirectPort="8433"
> secure="true"
> connectionTimeout="0"
> threadPriority="25"
> connectionUploadTimeout="0"
> connectionLinger="0"
> maxSpareThreads="100"
> maxThreads="500"
> maxKeepAliveRequests="250"
> disableUploadTimeout="false"
> uRIEncoding="ISO-8859-2"
> tcpNoDelay="false"
> minSpareThreads="4"
> acceptCount="60000"
> protocol="AJP/1.3">
> </Connector>
> ######## server.xml ###########
>
> Thanks in advance for any help.
> Best regards
> Artur
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org