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 <ch...@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) > <a...@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 >> <mart...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
