db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6510) Deby engine threads not making progress
Date Fri, 14 Mar 2014 18:28:42 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935364#comment-13935364
] 

Mike Matrigali edited comment on DERBY-6510 at 3/14/14 6:27 PM:
----------------------------------------------------------------

Do you have any idea what kind of cpu % would show up on that user machine if a single thread
were spinning
cpu bound for the 1 minute?  Trying to figure out if it is likely the optmizer thread is spinning
cpu bound or
not during that time.  It is very machine/OS/chip dependent and I am not sure what
the line in prstat means with regards to cpu.  Key thing I want to understand is if a 
thread in the jvm is spinning 100% cpu bound will this number be 100?  If 2 threads are
spinning and I assume they can be scheduled to different cpu's, then will number be 100,
200, or something else.

Are those 100 inserts per second likely to be 100 commits per second also? 

>I will attach the output of a "prstat" that was executed for 1 minute while the issue
was occurring. The PID for >derby is 4551 and you will see that about 11% to 12% of the
CPU was being utilized by Derby. Note that >Derby is also performing about 100 inserts/second
continuous into another table at the same time, so that will >account for some of that
CPU percentage.


was (Author: mikem):
Do you have any idea what kind of cpu % would show up on that user machine if a single thread
were spinning
cpu bound for the 1 minute?  Trying to figure out if it is likely the optmizer thread is spinning
cpu bound or
not during that time.  It is very machine/OS/chip dependent but what I usually see with many
cpu's per machine
now is that on a 4 processing unit machine a single thread spinning will register as 25% machine
busy.  It 
gets even harder to tell from the single number when multiple derby threads doing different
stuff is involved.

Are those 100 inserts per second likely to be 100 commits per second also? 

>I will attach the output of a "prstat" that was executed for 1 minute while the issue
was occurring. The PID for >derby is 4551 and you will see that about 11% to 12% of the
CPU was being utilized by Derby. Note that >Derby is also performing about 100 inserts/second
continuous into another table at the same time, so that will >account for some of that
CPU percentage.

> Deby engine threads not making progress
> ---------------------------------------
>
>                 Key: DERBY-6510
>                 URL: https://issues.apache.org/jira/browse/DERBY-6510
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.9.1.0
>         Environment: Oracle Solaris 10/9, Oracle M5000 32 CPU, 128GB memory, 8GB allocated
to Derby Network Server
>            Reporter: Brett Bergquist
>            Priority: Critical
>         Attachments: dbstate.log, derbystacktrace.txt, prstat.log, queryplan.txt
>
>
> We had an issue today in a production environment at a large customer site.   Basically
5 database interactions became stuck and are not progressing.   Part of the system dump performs
a stack trace every few seconds for a period of a minute on the Glassfish application server
and the Derby database engine (running in network server mode).   Also, the dump captures
the current transactions and the current lock table (ie. syscs_diag.transactions and syscs_diag.lock_table).
  We had to restart the system and in doing so, the Derby database engine would not shutdown
and had to be killed.
> The stack traces of the Derby engine show 5 threads that are basically making no progress
in that at each sample, they are at the same point, waiting.
> I will attach the stack traces as well as the state of the transactions and locks.  

> Interesting is that the "derby.jdbc.xaTransactionTimeout =1800" is set, yet the transactions
did not timeout.  The timeout is for 30 minutes but the transactions were in process for hours.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message