You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alejandro Henao González <de...@dqingenieria.com> on 2011/07/28 17:09:35 UTC
Problem with threads in stage Service (Tomcat 7.0.14)
Good day.
I have the following problem with my tomcat.
Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout for threads in service stage, or any solution??
Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
--------
Cordial saludo.
Tengo el siguiente problema con mi tomcat.
En algunas ocasiones , algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi aplicación web trabaja demasiado lento.
Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Pid <pi...@pidster.com>.
On 29/07/2011 08:41, André Warnier wrote:
> Pid wrote:
>> On 28/07/2011 20:07, Alejandro Henao González wrote:
>>> I dont believe that have GC running all the time, but the GC is
>>> called in the above line to HTMLEncoder.encode. as follows.
>>> System.gc();
>>> resultado = htmlEncoder.encode(resultado);
>>
>> Is 'htmlEncoder' a static field, an instance field or defined inside the
>> method scope?
>>
>>> response.reset();
>>
>> Why are you resetting the response?
>>
>>
> I'm not the real Java specialist here, but maybe one isn't really needed
> here.
> The code above seems to suggest that this application is forcing a major
> garbage collection at every request (or more). Is there a need to look
> anywhere else as to why this Tomcat is saturating the host's CPU and why
> threads are always suspended ?
>
> (Philip already pointed this out, but maybe he wasn't forceful enough in
> making the point)
The GC will cause problems, yes.
I am wondering whether the htmlEncoder is thread-safe too.
The response.reset() may be superfluous.
Just a little extra help...
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
> On 28/07/2011 20:07, Alejandro Henao González wrote:
>> I dont believe that have GC running all the time, but the GC is called in the above line to HTMLEncoder.encode. as follows.
>>
>> System.gc();
>>
>> resultado = htmlEncoder.encode(resultado);
>
> Is 'htmlEncoder' a static field, an instance field or defined inside the
> method scope?
>
>> response.reset();
>
> Why are you resetting the response?
>
>
I'm not the real Java specialist here, but maybe one isn't really needed here.
The code above seems to suggest that this application is forcing a major garbage
collection at every request (or more). Is there a need to look anywhere else as to why
this Tomcat is saturating the host's CPU and why threads are always suspended ?
(Philip already pointed this out, but maybe he wasn't forceful enough in making the point)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Pid <pi...@pidster.com>.
On 28/07/2011 20:07, Alejandro Henao González wrote:
> I dont believe that have GC running all the time, but the GC is called in the above line to HTMLEncoder.encode. as follows.
>
> System.gc();
>
> resultado = htmlEncoder.encode(resultado);
Is 'htmlEncoder' a static field, an instance field or defined inside the
method scope?
> response.reset();
Why are you resetting the response?
p
> may be this the problem? why?
>
>
> Thanks.
>
> ----- Mensaje original -----
>
> De: "Filip Hanik - Dev Lists" <de...@hanik.com>
> Para: "Tomcat Users List" <us...@tomcat.apache.org>
> Enviados: Jueves, 28 de Julio 2011 12:35:56
> Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
>
> most likely you have GC running all the time
>
> ""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
>
> this should not be a stage where you're stuck, unless you have a loop problem.
>
>
>
>
>
> On 7/28/2011 9:09 AM, Alejandro Henao González wrote:
>> Good day.
>>
>> I have the following problem with my tomcat.
>>
>> Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a
>> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
>>
>> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>>
>> The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout
>> for threads in service stage, or any solution??
>>
>> Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
>>
>>
>> --------
>>
>> Cordial saludo.
>>
>> Tengo el siguiente problema con mi tomcat.
>> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto
>> causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi
>> aplicación web trabaja demasiado lento.
>>
>> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>>
>> La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es
>> posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
>>
>> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by André Warnier <aw...@ice-sa.com>.
Alejandro Henao González wrote:
> I'm not sure that the problem is this.
> And, many JSPs have this line.
Well, that would certainly multiply the problem, wouldn't it ?
Do you have any idea what these "system.gc()" were meant to achieve ?
Anyway, nothing that find and grep and a good text editor can't solve.
> may be origin of problem is the hashmap static, because the method HTMLEncoder.encode not is static and the construct of HTMLEncoder initialize the object.
If you are not sure of your HTMLEncoder class, there are quite a few available that are
fully-tested.
A short search in Google for "java html encoder" shows a few, such as this one :
http://jtidy.sourceforge.net/multiproject/jtidyservlet/clover/org/w3c/tidy/servlet/util/HTMLEncode.html
(and there is another one in the Jakarta Commons).
Personally, instead of some kind of HashMap, I would just use a preset array of
String[128] with the translations of the first 128 char values (translating the inocuous
characters by themselves), and then translate everything else above 128 to "&#(char
value);". Intuitively, it would seem much faster than the complicated logic I see in
these classes (and yours).
But then, since I am no great Java expert, I may be missing something.
Getting back to the "system.gc()" however, I am pretty sure that if every access to a JSP
page on that system triggers a major GC, then there is no wonder about where your system's
CPU time is being spent.
That is also what Philip seemed to say in his comment to your thread dump. And he
definitely is a Java and Tomcat expert.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
I'm not sure that the problem is this. And, many JSPs have this line. may be origin of problem is the hashmap static, because the method HTMLEncoder.encode not is static and the construct of HTMLEncoder initialize the object.
----- Mensaje original -----
De: "André Warnier" <aw...@ice-sa.com>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviados: Viernes, 29 de Julio 2011 12:36:21
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
Alejandro Henao González wrote:
> ummm...
> The option -XX:-DisableExplicitGC not solves the problem, may be with the +DisableExplicitGC, i will try it.
>
ummm..
A mystery for me is : since you have the source, why do you not just comment out the
system.gc();
line, and see what your Tomcat is then doing ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by André Warnier <aw...@ice-sa.com>.
Alejandro Henao González wrote:
> ummm...
> The option -XX:-DisableExplicitGC not solves the problem, may be with the +DisableExplicitGC, i will try it.
>
ummm..
A mystery for me is : since you have the source, why do you not just comment out the
system.gc();
line, and see what your Tomcat is then doing ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Pid <pi...@pidster.com>.
On 02/08/2011 02:11, Christopher Schultz wrote:
>> > public HTMLEncoder() { mapChar2HTMLEntity= new HashMap(); int
>> > longueur = characters.length;
>> >
>> > for (int i = 0; i < longueur; i++) mapChar2HTMLEntity.put(new
>> > Character(characters[i]), entities[i]); }
> So you have Character -> String (entity reference). Your Map is not
> synchronized, but it doesn't have to be: you are only calling get() on
> it so there shouldn't be any synchronization issues here.
The static 'mapChar2HTMLEntity' field is re-initialised each time a new
instance is created.
If a read event is occurring in another thread at the same time, what
will happen?
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
Thanks to all. The problem was the static hashmap. I removed the static keyword to the variable and problem solved.
----- Mensaje original -----
De: "Christopher Schultz" <ch...@christopherschultz.net>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviados: Lunes, 1 de Agosto 2011 20:11:27
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alejandro,
On 7/29/2011 11:55 AM, Alejandro Henao González wrote:
> public class HTMLEncoder { private static Map mapChar2HTMLEntity;
>
> private final static char [] characters = {
> 'á','ú','ó','é','í','ñ','Á','Ú','Ó','É','Í','°','ü' }; private final
> static String[] entities = {
> "á","ú","ó","é","í","ñ","Á","Ú","Ó","É","Í","°","ü"
> };
>
> public HTMLEncoder() { mapChar2HTMLEntity= new HashMap(); int
> longueur = characters.length;
>
> for (int i = 0; i < longueur; i++) mapChar2HTMLEntity.put(new
> Character(characters[i]), entities[i]); }
So you have Character -> String (entity reference). Your Map is not
synchronized, but it doesn't have to be: you are only calling get() on
it so there shouldn't be any synchronization issues here.
> public String encode(String s) { int longueur = s.length(); final
> StringBuffer sb = new StringBuffer(longueur * 2);
Big buffer every time?
> char ch;
>
> for (int i =0; i < longueur ; ++i) { ch = s.charAt(i);
>
> if ((ch >= 63 && ch <= 90) || (ch >= 97 && ch <= 122)) sb.append(ch);
> else { String ss = (String)mapChar2HTMLEntity.get(new
> Character(ch));
New Character object every time? Mmm. You might want to choose a more
optimized storage system so you don't have to create a new object every
time.
> if(ss==null) sb.append(ch); else sb.append(ss); } } return
> sb.toString(); }
Aside from any other strange issues you are having, you might be wasting
a lot of time (and invoking a lot of GC) by creating a large
StringBuffer for every invocation. You might want some more complicated
logic to determine if you even need to create such a buffer.
Honestly, I don't see much wrong with this class. I don't see any use of
System.gc and I don't see any connection reset. Was there a post that I
missed?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk43Tr4ACgkQ9CaO5/Lv0PBk4QCglB4MNYVbEvwsqZFwiOYupAUv
J84AnRAnw2o6PwTRiaNnNFc9iyNq0pUS
=UWQu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alejandro,
On 7/29/2011 11:55 AM, Alejandro Henao González wrote:
> public class HTMLEncoder { private static Map mapChar2HTMLEntity;
>
> private final static char [] characters = {
> 'á','ú','ó','é','í','ñ','Á','Ú','Ó','É','Í','°','ü' }; private final
> static String[] entities = {
> "á","ú","ó","é","í","ñ","Á","Ú","Ó","É","Í","°","ü"
> };
>
> public HTMLEncoder() { mapChar2HTMLEntity= new HashMap(); int
> longueur = characters.length;
>
> for (int i = 0; i < longueur; i++) mapChar2HTMLEntity.put(new
> Character(characters[i]), entities[i]); }
So you have Character -> String (entity reference). Your Map is not
synchronized, but it doesn't have to be: you are only calling get() on
it so there shouldn't be any synchronization issues here.
> public String encode(String s) { int longueur = s.length(); final
> StringBuffer sb = new StringBuffer(longueur * 2);
Big buffer every time?
> char ch;
>
> for (int i =0; i < longueur ; ++i) { ch = s.charAt(i);
>
> if ((ch >= 63 && ch <= 90) || (ch >= 97 && ch <= 122)) sb.append(ch);
> else { String ss = (String)mapChar2HTMLEntity.get(new
> Character(ch));
New Character object every time? Mmm. You might want to choose a more
optimized storage system so you don't have to create a new object every
time.
> if(ss==null) sb.append(ch); else sb.append(ss); } } return
> sb.toString(); }
Aside from any other strange issues you are having, you might be wasting
a lot of time (and invoking a lot of GC) by creating a large
StringBuffer for every invocation. You might want some more complicated
logic to determine if you even need to create such a buffer.
Honestly, I don't see much wrong with this class. I don't see any use of
System.gc and I don't see any connection reset. Was there a post that I
missed?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk43Tr4ACgkQ9CaO5/Lv0PBk4QCglB4MNYVbEvwsqZFwiOYupAUv
J84AnRAnw2o6PwTRiaNnNFc9iyNq0pUS
=UWQu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
ummm...
The option -XX:-DisableExplicitGC not solves the problem, may be with the +DisableExplicitGC, i will try it.
The method HTMLEncoder.encode is static and uses a HashMap static. this is the class.
public class HTMLEncoder {
private static Map mapChar2HTMLEntity;
private final static char [] characters = {
'á','ú','ó','é','í','ñ','Á','Ú','Ó','É','Í','°','ü'
};
private final static String[] entities = {
"á","ú","ó","é","í","ñ","Á","Ú","Ó","É","Í","°","ü"
};
public HTMLEncoder() {
mapChar2HTMLEntity= new HashMap();
int longueur = characters.length;
for (int i = 0; i < longueur; i++)
mapChar2HTMLEntity.put(new Character(characters[i]), entities[i]);
}
public String encode(String s) {
int longueur = s.length();
final StringBuffer sb = new StringBuffer(longueur * 2);
char ch;
for (int i =0; i < longueur ; ++i) {
ch = s.charAt(i);
if ((ch >= 63 && ch <= 90) || (ch >= 97 && ch <= 122))
sb.append(ch);
else {
String ss = (String)mapChar2HTMLEntity.get(new Character(ch));
if(ss==null)
sb.append(ch);
else
sb.append(ss);
}
}
return sb.toString();
}
public StringBuffer encode(StringBuffer s) {
int longueur = s.length();
final StringBuffer sb = new StringBuffer(longueur * 2);
char ch;
for (int i =0; i < longueur ; ++i) {
ch = s.charAt(i);
if ((ch >= 63 && ch <= 90) || (ch >= 97 && ch <= 122))
sb.append(ch);
else {
String ss = (String)mapChar2HTMLEntity.get(new Character(ch));
if(ss==null)
sb.append(ch);
else
sb.append(ss);
}
}
return sb;
}
}
----- Mensaje original -----
De: "Rainer Jung" <ra...@kippdata.de>
Para: users@tomcat.apache.org
Enviados: Viernes, 29 de Julio 2011 5:05:37
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
On 28.07.2011 21:20, Filip Hanik - Dev Lists wrote:
> that's an academic exercise for you, in the meantime, add in this option
> to your startup options
> -XX:-DisableExplicitGC
I think Filip wanted to suggest -XX:+DisableExplicitGC
The plus or minus after the colon decides whether the switch is set or
unset. So in this case we want to set a disable switch (which will only
be a workaround).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Rainer Jung <ra...@kippdata.de>.
On 28.07.2011 21:20, Filip Hanik - Dev Lists wrote:
> that's an academic exercise for you, in the meantime, add in this option
> to your startup options
> -XX:-DisableExplicitGC
I think Filip wanted to suggest -XX:+DisableExplicitGC
The plus or minus after the colon decides whether the switch is set or
unset. So in this case we want to set a disable switch (which will only
be a workaround).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
Ok. i will trie with this option.
----- Mensaje original -----
De: "Filip Hanik - Dev Lists" <de...@hanik.com>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviados: Jueves, 28 de Julio 2011 14:20:26
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
that's an academic exercise for you, in the meantime, add in this option to your startup options
-XX:-DisableExplicitGC
Filip
On 7/28/2011 1:07 PM, Alejandro Henao González wrote:
> I dont believe that have GC running all the time, but the GC is called in the above line to HTMLEncoder.encode. as follows.
>
>
>
> System.gc();
>
>
> resultado = htmlEncoder.encode(resultado);
> response.reset();
>
>
> may be this the problem? why?
>
>
> Thanks.
>
> ----- Mensaje original -----
>
> De: "Filip Hanik - Dev Lists"<de...@hanik.com>
> Para: "Tomcat Users List"<us...@tomcat.apache.org>
> Enviados: Jueves, 28 de Julio 2011 12:35:56
> Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
>
> most likely you have GC running all the time
>
> ""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
>
> this should not be a stage where you're stuck, unless you have a loop problem.
>
>
>
>
>
> On 7/28/2011 9:09 AM, Alejandro Henao González wrote:
>> Good day.
>>
>> I have the following problem with my tomcat.
>>
>> Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a
>> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
>>
>> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>>
>> The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout
>> for threads in service stage, or any solution??
>>
>> Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
>>
>>
>> --------
>>
>> Cordial saludo.
>>
>> Tengo el siguiente problema con mi tomcat.
>> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto
>> causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi
>> aplicación web trabaja demasiado lento.
>>
>> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>>
>> La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es
>> posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
>>
>> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
that's an academic exercise for you, in the meantime, add in this option to your startup options
-XX:-DisableExplicitGC
Filip
On 7/28/2011 1:07 PM, Alejandro Henao González wrote:
> I dont believe that have GC running all the time, but the GC is called in the above line to HTMLEncoder.encode. as follows.
>
>
>
> System.gc();
>
>
> resultado = htmlEncoder.encode(resultado);
> response.reset();
>
>
> may be this the problem? why?
>
>
> Thanks.
>
> ----- Mensaje original -----
>
> De: "Filip Hanik - Dev Lists"<de...@hanik.com>
> Para: "Tomcat Users List"<us...@tomcat.apache.org>
> Enviados: Jueves, 28 de Julio 2011 12:35:56
> Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
>
> most likely you have GC running all the time
>
> ""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
>
> this should not be a stage where you're stuck, unless you have a loop problem.
>
>
>
>
>
> On 7/28/2011 9:09 AM, Alejandro Henao González wrote:
>> Good day.
>>
>> I have the following problem with my tomcat.
>>
>> Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a
>> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
>>
>> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>>
>> The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout
>> for threads in service stage, or any solution??
>>
>> Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
>>
>>
>> --------
>>
>> Cordial saludo.
>>
>> Tengo el siguiente problema con mi tomcat.
>> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto
>> causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi
>> aplicación web trabaja demasiado lento.
>>
>> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>>
>> La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es
>> posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
>>
>> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
I dont believe that have GC running all the time, but the GC is called in the above line to HTMLEncoder.encode. as follows.
System.gc();
resultado = htmlEncoder.encode(resultado);
response.reset();
may be this the problem? why?
Thanks.
----- Mensaje original -----
De: "Filip Hanik - Dev Lists" <de...@hanik.com>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviados: Jueves, 28 de Julio 2011 12:35:56
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
most likely you have GC running all the time
""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
this should not be a stage where you're stuck, unless you have a loop problem.
On 7/28/2011 9:09 AM, Alejandro Henao González wrote:
> Good day.
>
> I have the following problem with my tomcat.
>
> Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a
> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
>
> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>
> The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout
> for threads in service stage, or any solution??
>
> Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
>
>
> --------
>
> Cordial saludo.
>
> Tengo el siguiente problema con mi tomcat.
> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto
> causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi
> aplicación web trabaja demasiado lento.
>
> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>
> La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es
> posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
>
> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
most likely you have GC running all the time
""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
this should not be a stage where you're stuck, unless you have a loop problem.
On 7/28/2011 9:09 AM, Alejandro Henao González wrote:
> Good day.
>
> I have the following problem with my tomcat.
>
> Sometimes, some threads are keep in service stage for a long time (really never exit from this stage), this causes that tomcat uses a
> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp executes very slow.
>
> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>
> The partial solution is restart the service, but this is not a practical solution(because is a 24/7 server). is posible config a timeout
> for threads in service stage, or any solution??
>
> Thanks. Sorry for the redaction. Attached an image with the tomcat manager status and the CPU consuming.
>
>
> --------
>
> Cordial saludo.
>
> Tengo el siguiente problema con mi tomcat.
> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio por demasiado tiempo (de hecho nunca salen de esta etapa), esto
> causa que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos incluso hasta los 8 a veces), y en consecuencia mi
> aplicación web trabaja demasiado lento.
>
> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>
> La solución temporal que tengo es reiniciar el servicio, sin embargo esta no es una solución práctica (pues debe ser un servidor 24/7). Es
> posible configurar algún timeout para hilos en la etapa de servicio, o alguna solución alternativa para este problema?
>
> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat Manager, y el uso de la CPU
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Alejandro Henao González <de...@dqingenieria.com>.
Ok. i have the Thread Dump. Analyzing, the problem is with the class HashMap. here is the thread thump. I've highlighted in red the Threads with the problem.
Any solution? could be a programation error of the webapp?
Thanks.
2011-07-28 11:26:30
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.0-b11 mixed mode):
"Attach Listener" daemon prio=10 tid=0x00002aaab28f8000 nid=0x637e waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
""http-bio-80"-exec-169" daemon prio=10 tid=0x00002aaab2b6a000 nid=0x5bcf waiting on condition [0x0000000043bb1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-168" daemon prio=10 tid=0x00002aaab8312800 nid=0x5bcc waiting on condition [0x0000000040209000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-167" daemon prio=10 tid=0x00002aaab8345000 nid=0x5bcb waiting on condition [0x00000000433a9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-166" daemon prio=10 tid=0x00002aaab3244800 nid=0x5bc9 waiting on condition [0x00000000439af000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-165" daemon prio=10 tid=0x00002aaab3f0a000 nid=0x5bc8 waiting on condition [0x00000000405a6000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-164" daemon prio=10 tid=0x00002aaab29bd800 nid=0x5bb0 waiting on condition [0x000000004279d000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-161" daemon prio=10 tid=0x00002aaab3f09000 nid=0x56ae waiting on condition [0x0000000043ab0000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-exec-157" daemon prio=10 tid=0x00002aaab28fe000 nid=0x5519 waiting on condition [0x0000000042aa0000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0a2bad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-18" daemon prio=10 tid=0x00002aaab2767000 nid=0xad3 waiting on condition [0x00000000430a6000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-17" daemon prio=10 tid=0x00002aaab26db800 nid=0xaca waiting on condition [0x000000004289e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-16" daemon prio=10 tid=0x00002aaab2768000 nid=0xabe waiting on condition [0x00000000432a8000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-15" daemon prio=10 tid=0x00002aaab2ebc000 nid=0x4d2 runnable [0x000000004299f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:478)
at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:562)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:237)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:183)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:169)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e4e71848> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e4e718c8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
""ajp-bio-8009"-exec-14" daemon prio=10 tid=0x00002aaab2ebb800 nid=0x4d1 waiting on condition [0x00000000431a7000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-13" daemon prio=10 tid=0x00002aaab2da9000 nid=0x4d0 waiting on condition [0x0000000042fa5000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-12" daemon prio=10 tid=0x00002aaab27c4800 nid=0x3e5 waiting on condition [0x0000000042ba1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000e0ade9d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-11" daemon prio=10 tid=0x00002aaab2e33800 nid=0x3e4 runnable [0x00000000434aa000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:478)
at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:562)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:237)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:183)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:169)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e6207238> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e4d9fd00> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
""ajp-bio-8009"-exec-10" daemon prio=10 tid=0x00002aaab29b0000 nid=0x7fd0 runnable [0x0000000042ca2000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:478)
at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:562)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:237)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:183)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:169)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e4d115b0> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e4d11688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
""http-bio-80"-exec-107" daemon prio=10 tid=0x00002aaab31ea000 nid=0x47b2 runnable [0x00000000436ab000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
at org.apache.jsp.buscarDobleColumna_jsp._jspService(buscarDobleColumna_jsp.java:137)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:182)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e5706680> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e48dd6b0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
""http-bio-80"-exec-89" daemon prio=10 tid=0x00002aaab31bc000 nid=0x34c7 runnable [0x00000000435aa000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at sae.HTMLEncoder.encode(HTMLEncoder.java:46)
at org.apache.jsp.buscarDobleColumna_jsp._jspService(buscarDobleColumna_jsp.java:137)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:182)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e57066c8> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e42ca1a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"Java2D Disposer" daemon prio=10 tid=0x00002aaab43ae800 nid=0x2eed in Object.wait() [0x000000004035a000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e1316940> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x00000000e1316940> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at sun.java2d.Disposer.run(Disposer.java:127)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-exec-2" daemon prio=10 tid=0x00002aaab2db1800 nid=0x22ba runnable [0x0000000040a18000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:478)
at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:562)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:237)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:183)
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:169)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
- locked <0x00000000e0dd8790> (a org.apache.tomcat.util.net.SocketWrapper)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000000e0dd8868> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
""ajp-bio-8009"-AsyncTimeout" daemon prio=10 tid=0x00002aaab2ba4000 nid=0x1efa waiting on condition [0x000000004249a000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.tomcat.util.net.JIoEndpoint$AsyncTimeout.run(JIoEndpoint.java:151)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""ajp-bio-8009"-Acceptor-0" daemon prio=10 tid=0x00002aaab2fbf800 nid=0x1ef9 runnable [0x0000000042399000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x00000000e03c2b68> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-AsyncTimeout" daemon prio=10 tid=0x00002aaab2846800 nid=0x1ef7 waiting on condition [0x0000000040b75000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.tomcat.util.net.JIoEndpoint$AsyncTimeout.run(JIoEndpoint.java:151)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
""http-bio-80"-Acceptor-0" daemon prio=10 tid=0x00002aaab2fbe800 nid=0x1ef6 runnable [0x0000000040917000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x00000000e01e5be0> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59)
at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=10 tid=0x00002aaab2aee000 nid=0x1ef5 waiting on condition [0x0000000042298000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1369)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
"GC Daemon" daemon prio=10 tid=0x00002aaab29a9000 nid=0x1eed in Object.wait() [0x0000000042197000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0000140> (a sun.misc.GC$LatencyLock)
at sun.misc.GC$Daemon.run(GC.java:100)
- locked <0x00000000e0000140> (a sun.misc.GC$LatencyLock)
Locked ownable synchronizers:
- None
"Low Memory Detector" daemon prio=10 tid=0x00002aaab248b000 nid=0x1eeb runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"C2 CompilerThread1" daemon prio=10 tid=0x00002aaab2488800 nid=0x1eea waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"C2 CompilerThread0" daemon prio=10 tid=0x00002aaab2485000 nid=0x1ee9 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Signal Dispatcher" daemon prio=10 tid=0x00002aaab2483000 nid=0x1ee8 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Finalizer" daemon prio=10 tid=0x0000000040e4a800 nid=0x1ee7 in Object.wait() [0x0000000041a97000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0000380> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x00000000e0000380> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
Locked ownable synchronizers:
- None
"Reference Handler" daemon prio=10 tid=0x0000000040e43000 nid=0x1ee6 in Object.wait() [0x0000000041996000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e0000120> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x00000000e0000120> (a java.lang.ref.Reference$Lock)
Locked ownable synchronizers:
- None
"main" prio=10 tid=0x0000000040dd7000 nid=0x1edc runnable [0x0000000040f65000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x00000000e0a5b6b8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at org.apache.catalina.core.StandardServer.await(StandardServer.java:447)
at org.apache.catalina.startup.Catalina.await(Catalina.java:707)
at org.apache.catalina.startup.Catalina.start(Catalina.java:653)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431)
Locked ownable synchronizers:
- None
"VM Thread" prio=10 tid=0x0000000040e3c800 nid=0x1ee5 runnable
"GC task thread#0 (ParallelGC)" prio=10 tid=0x0000000040dea000 nid=0x1edd runnable
"GC task thread#1 (ParallelGC)" prio=10 tid=0x0000000040deb800 nid=0x1ede runnable
"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000040ded800 nid=0x1edf runnable
"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000040def800 nid=0x1ee0 runnable
"GC task thread#4 (ParallelGC)" prio=10 tid=0x0000000040df1000 nid=0x1ee1 runnable
"GC task thread#5 (ParallelGC)" prio=10 tid=0x0000000040df3000 nid=0x1ee2 runnable
"GC task thread#6 (ParallelGC)" prio=10 tid=0x0000000040df5000 nid=0x1ee3 runnable
"GC task thread#7 (ParallelGC)" prio=10 tid=0x0000000040df6800 nid=0x1ee4 runnable
"VM Periodic Task Thread" prio=10 tid=0x00002aaab2495800 nid=0x1eec waiting on condition
JNI global references: 1425
----- Mensaje original -----
De: "Pid" <pi...@pidster.com>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviados: Jueves, 28 de Julio 2011 10:44:37
Asunto: Re: Problem with threads in stage Service (Tomcat 7.0.14)
On 28/07/2011 16:09, Alejandro Henao González wrote:
> Good day.
>
> I have the following problem with my tomcat.
>
> Sometimes, some threads are keep in service stage for a long time
> (really never exit from this stage), this causes that tomcat uses a
> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp
> executes very slow.
Take a thread dump when this is occurring.
http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics
p
> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>
> The partial solution is restart the service, but this is not a practical
> solution(because is a 24/7 server). is posible config a timeout for
> threads in service stage, or any solution??
>
> Thanks. Sorry for the redaction. Attached an image with the tomcat
> manager status and the CPU consuming.
>
>
> --------
>
> Cordial saludo.
>
> Tengo el siguiente problema con mi tomcat.
> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio
> por demasiado tiempo (de hecho nunca salen de esta etapa), esto causa
> que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos
> incluso hasta los 8 a veces), y en consecuencia mi aplicación web
> trabaja demasiado lento.
>
> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>
> La solución temporal que tengo es reiniciar el servicio, sin embargo
> esta no es una solución práctica (pues debe ser un servidor 24/7). Es
> posible configurar algún timeout para hilos en la etapa de servicio, o
> alguna solución alternativa para este problema?
>
> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat
> Manager, y el uso de la CPU
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with threads in stage Service (Tomcat 7.0.14)
Posted by Pid <pi...@pidster.com>.
On 28/07/2011 16:09, Alejandro Henao González wrote:
> Good day.
>
> I have the following problem with my tomcat.
>
> Sometimes, some threads are keep in service stage for a long time
> (really never exit from this stage), this causes that tomcat uses a
> hight percentage of the CPU (100 % of 2 or 3 cores) thus the webapp
> executes very slow.
Take a thread dump when this is occurring.
http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics
p
> I have a Tomcat 7.0.14 in a Redhat RHLE 5.5.
>
> The partial solution is restart the service, but this is not a practical
> solution(because is a 24/7 server). is posible config a timeout for
> threads in service stage, or any solution??
>
> Thanks. Sorry for the redaction. Attached an image with the tomcat
> manager status and the CPU consuming.
>
>
> --------
>
> Cordial saludo.
>
> Tengo el siguiente problema con mi tomcat.
> En algunas ocasiones, algunos hilos se quedan en la etapa de servicio
> por demasiado tiempo (de hecho nunca salen de esta etapa), esto causa
> que el tomcat use un alto porcenta de la CPU (el 100 % de 2 o 3 núcluos
> incluso hasta los 8 a veces), y en consecuencia mi aplicación web
> trabaja demasiado lento.
>
> Tengo el Tomcat 7.0.14 en Redhat RHLE 5.5
>
> La solución temporal que tengo es reiniciar el servicio, sin embargo
> esta no es una solución práctica (pues debe ser un servidor 24/7). Es
> posible configurar algún timeout para hilos en la etapa de servicio, o
> alguna solución alternativa para este problema?
>
> Muchas Gracias. Adjunto una imagen del reporte del estado por el tomcat
> Manager, y el uso de la CPU
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org