[ http://issues.apache.org/jira/browse/DERBY-799?page=all ]
Øystein Grøvlen updated DERBY-799:
----------------------------------
Description:
We have observed that during checkpointing, transaction response times for
small transactions may become very long. Extra trace output in the log showed
that this was due to long response times for disk I/O. I observed that some
read and write operations took more than 20 seconds.
The believed reason for the long response times is that the file system buffer
may be overflowed during checkpointing. During checkpointing, Derby writes all
dirty pages to the file system buffer and then syncs at the end. I tried
syncing a file for every 100th write and that improved the situation a bit.
The following derby-dev threads discusses this issue:
http://www.nabble.com/-jira-Created%3A-%28DERBY-733%29-Starvation-in-RAFContainer.readPage%28%29-t646257.html#a1975574
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html#a1294290
I will file another JIRA issue for the related issue of concurrent access to
the same file.
was:
We have observed that during checkpointing, transaction response times for
small transactions may become very long. Extra trace output in the log showed
that this was due to long response times for disk I/O. I observed that some
read and write operations took more than 20 seconds.
The believed reason for the long response times is that the file system buffer
may be overflowed during checkpointing. During checkpointing, Derby writes all
dirty pages to the file system buffer and then syncs at the end. I tried
syncing a file for every 100th write and that improved the situation a bit.
The following derby-dev threads discusses this issue:
http://www.nabble.com/-jira-Created%3A-%28DERBY-733%29-Starvation-in-RAFContainer.readPage%28%29-t646257.html#a1975574
I will file another JIRA issue for the related issue of concurrent access to
the same file.
Added a link to another derby-dev thread that discusses this issue.
> Large response times during checkpointing on disk-bound systems
> ---------------------------------------------------------------
>
> Key: DERBY-799
> URL: http://issues.apache.org/jira/browse/DERBY-799
> Project: Derby
> Type: Improvement
> Components: Performance, Store
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0,
> 10.1.2.1
> Environment: Observed on both Solaris and Linux with Sun VM.
> Reporter: Øystein Grøvlen
>
> We have observed that during checkpointing, transaction response times for
> small transactions may become very long. Extra trace output in the log
> showed that this was due to long response times for disk I/O. I observed
> that some read and write operations took more than 20 seconds.
> The believed reason for the long response times is that the file system
> buffer may be overflowed during checkpointing. During checkpointing, Derby
> writes all dirty pages to the file system buffer and then syncs at the end.
> I tried syncing a file for every 100th write and that improved the situation
> a bit.
> The following derby-dev threads discusses this issue:
> http://www.nabble.com/-jira-Created%3A-%28DERBY-733%29-Starvation-in-RAFContainer.readPage%28%29-t646257.html#a1975574
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html#a1294290
> I will file another JIRA issue for the related issue of concurrent access to
> the same file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
