[jira] [Comment Edited] (DERBY-6510) Deby engine threads not making progress

["Mike Matrigali (JIRA)" <ji...@apache.org>]

    [ 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)