tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tullio Bettinazzi <tullio0...@live.it>
Subject Re: Strange wait time in my application - Tomcat 7.0.67
Date Sun, 23 Oct 2016 13:52:53 GMT
I'm sure is noty a Db issue, the delay is not only concentrated in db functions.

The same DB operations seems to take from 4millsec to 4 sec with same data and parameters.

Tks



________________________________
Da: Christopher Schultz <chris@christopherschultz.net>
Inviato: venerdì 21 ottobre 2016 23.07
A: Tomcat Users List
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Tullio,

On 10/17/16 12:24 PM, Tullio Bettinazzi wrote:
> I monitored it using Yourkit profiler and I didn't see any extreme
> GC.
>
> I noticed anotehr thing : looking for 4 users which had the
> problem they seems to have the problem "in sequence".
>
> The first user "stops" for 4 seconds then another one "stops" and
> so on : they don't seem to stop at the sam time (as it would be
> expected in case of GC) but in sequence.

My first reaction is that this has to be a database issue. Are you
using a traditional RDBMS under the hood? Can you look for
long-running queries on the db? Maybe you have a table that is being
locked during a transaction which is holding-up users.

Maybe you have a database connection pool without enough connections
in it.

During times of heavy traffic, when you have users "stalling", what
does a thread dump show you?

- -chris

> ________________________________ Da: André Warnier (tomcat)
> <aw@ice-sa.com> Inviato: lunedì 17 ottobre 2016 18.01 A:
> users@tomcat.apache.org Oggetto: Re: Strange wait time in my
> application - Tomcat 7.0.67
>
> On 17.10.2016 17:52, Tullio Bettinazzi wrote:
>> I didn't find any solution to my problem.
>>
>> Could someone provide suggestions or a strategy to find the
>> solution ?
>>
>
> "I don't see relevant garbage collection : heap size and permgen
> have correct dimentions."
>
> Define "correct".  Are you really *logging* the JVM Garbage
> Collection, and do you *know* that this is not the issue ?
>
> (Note that 4 seconds seems an awfully long time for a GC; but one
> would want to eliminate this with certainty, before looking any
> further).
>
>
>>
>>
>> ________________________________ Da: Martijn Bos
>> <martijn@maboc.nl> Inviato: lunedì 3 ottobre 2016 21.05 A: Tomcat
>> Users List Oggetto: Re: Strange wait time in my application -
>> Tomcat 7.0.67
>>
>> On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:
>>> I've an application under tomcat. When only a one or two users
>>> works on it everithing is ok. When the number of users grows
>>> the application slows down. Is not a memory nor a cpu problem :
>>> using top I see the system resources quite free. I don't see
>>> relevant garbage collection : heap size and permgen have
>>> correct dimentions. No other applications are running on the
>>> system. I log more or less every relevant operation in my
>>> system (db query and so on) and I see that every slowdown is
>>> concentered in a single operation. I mean all operations take
>>> "normal" time but one or two of them take 4 seconds more. The
>>> "slowing" operations are not the same in different executions,
>>> and theydo not have a specific type (not only DB query, not
>>> only DB stored procedures, not only.....). It seems like if the
>>> thread is frozen for a fixed amount fo time (4 seconds more or
>>> less) and then it restarts. I don't think it's a "queue"
>>> problem because otherwise the wait time would be unperdictable
>>> and not a "fixed" 4 seconds time. I don't know any parameter
>>> impacting on that behaviour. I use Tomcat 7.0.32 with JVM
>>> 1.7.0.67 on a Linux server. Could someone suggest a solution
>>> for my problem or, at least, an investigation strategy. Tks
>>>
>>> Tullio
>>>
>>
>>
>> The few examples that you mention are all database related
>> (query/stored procedure). Can it be that your connection pool (if
>> used) combined with not closing connections is part of the
>> problem.
>>
>> I can imagine : 1) Maybe you run out of conenctions, because
>> connections are not properly closed. And also the connection pool
>> teminates connections when they are not used for 4 seconds. After
>> 4 seconds the pool can recreate connections again.
>>
>> or 2) Maybe your connection pool has very limited connections.
>> With one or two users this limited number of connections in the
>> pool will suffice. If there are more users, the max. number of
>> connections isn't enough. The pool then has to wait for
>> connections to become fee again.
>>
>>
>> (uhh....I'm not an expert at all, but the above came immediately
>> to my mind)
>>
>> -- Met vriendelijke groet,
>>
>> Martijn Bos +31 6 39477001
>>
>> (Public pgp-key : http://maboc.nl/pubkey.maboc.asc)
maboc.nl<http://maboc.nl/pubkey.maboc.asc>
maboc.nl
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -----BEGIN PGP
maboc.nl<http://maboc.nl/pubkey.maboc.asc>
maboc.nl
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> PUBLIC KEY BLOCK----- Version: GnuPG v1
> mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
> sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
>
>
>
>> maboc.nl<http://maboc.nl/pubkey.maboc.asc>
maboc.nl<http://maboc.nl/pubkey.maboc.asc>
maboc.nl
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -----BEGIN PGP
maboc.nl<http://maboc.nl/pubkey.maboc.asc>
maboc.nl
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> PUBLIC KEY BLOCK----- Version: GnuPG v1
> mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
> sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
>
>
>
>> maboc.nl -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1
>> mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk
>> sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYCoOoAAoJEBzwKT+lPKRYpIYQAJulUKd5yk5zOsN2ZhxQgVrg
brDnooS8oDM2quXCopdIk1Oub0h2yX9ExdY/lx9xdPQezZEhkYEFMx7JGtZk6VrM
isLBjEiNKKH/hMG1j0wDTSZuET92gYZp8qLzmy/ISK22npLRxHIsRUVJ8Bt55J5r
++ddV2XgX1aj1Ap6z03NAzmz+1TtQlJfc17xVpPjktiipneVyL0o6p3+LqzX12Zy
kPmF5JSNif9H9zc3di73KcFXrWNrtf6q8hhtHkiJmuLD7COpG/hSajh7rS+VuoJP
+HLagSFft9l4Qru6nn+WHVXE86dGnE2frhJRDPZ+WIjK3ce2oEi7TwtEJXLil8v6
NFXRUX0T7zlOjJoE4CJWgZNAIwp2OeENkOJGqQ9IYOaar4BkOz/3ksORqsT1XXTj
sVUoRUtKkdXl5a0oSrGqOAjHmMghNxTpkp9S/iFatIhK1RcX+Rhg0c9Z/kiPP1a7
CTtaupF07XatpPKbckm3J2cmjG160cTlsc3+hj2q3XELgCfpIvZq2hAZAVncBebe
y2+kIZisZ2dpT26UPw3h44aR8mEBdhKHDjuCLsNacjiCidd/+m16aq5enPzn6oVf
r9oOAhjh8BBhlEB0vgqCOHAud6607w6DnxFtORTRk8KI+JYwF76oXI7LUD/IG6tw
0GPgcLiOhP4NTjWNrjeE
=XAvl
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message