You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Øystein Grøvlen (JIRA)" <de...@db.apache.org> on 2006/01/06 16:23:15 UTC
[jira] Created: (DERBY-799) Large response times during
checkpointing on disk-bound systems
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
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
[jira] Updated: (DERBY-799) Large response times during
checkpointing on disk-bound systems
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-799:
--------------------------------
Derby Categories: [Performance]
> Large response times during checkpointing on disk-bound systems
> ---------------------------------------------------------------
>
> Key: DERBY-799
> URL: https://issues.apache.org/jira/browse/DERBY-799
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-799) Large response times during
checkpointing on disk-bound systems
Posted by "Øystein Grøvlen (JIRA)" <de...@db.apache.org>.
[ 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