[
https://issues.apache.org/jira/browse/DERBY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935422#comment-13935422
]
Brett Bergquist commented on DERBY-6510:
----------------------------------------
Not really sure as I have limited visibility into the customer's system and
typically only see stuff when something bad happens ;) I will try to find out
but I think it was about 3 to 5% normally.
The 100 inserts/second are 100 commits/second as well. Right now there is no
batching of the updates.
Is there any way to tell if the "derby.optimizer.noTimeout=true" is taking
effect? I set this in "derby.properties" and then restarted the network server
and re-rand the query. I will attach the query plan but here is the
statistics that I see:
Parse Time: 42
Bind Time: 72
Optimize Time: 13161
Generate Time: 43
Compile Time: 13318
Execute Time: 21
Begin Compilation Timestamp : 2014-03-14 14:36:07.52
End Compilation Timestamp : 2014-03-14 14:36:20.838
Begin Execution Timestamp : 2014-03-14 14:36:20.854
End Execution Timestamp : 2014-03-14 14:36:20.877
So it appears the optimizer time went up by a factor of 10 but I just want to
make sure that the setting is being recognized.
> 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)
