activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6771) Improve performance of KahaDB recovery check checkForCorruptJournalFiles=true
Date Mon, 17 Jul 2017 13:44:01 GMT

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

Gary Tully commented on AMQ-6771:
---------------------------------

[~cshannon] I don't have great numbers from my local testing b/c I am on a ssd and seek is
very fast. I saw some strace from a user where the repeated fseek/read was very slow.  The
current sequential read in batches eliminates the fseek. Would be great to get some early
validation. Thanks.

> Improve performance of KahaDB recovery check checkForCorruptJournalFiles=true
> -----------------------------------------------------------------------------
>
>                 Key: AMQ-6771
>                 URL: https://issues.apache.org/jira/browse/AMQ-6771
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: KahaDB
>    Affects Versions: 5.15.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.16.0
>
>
> The KahaDB checkForCorruptJournalFiles option validates the checksum of every journal
batch record on startup. If a single producer writes many small messages, the batch sizes
in the journal will be small. The current check implementation reads each batch at a time
with a fseek/read sequence that can be very slow over shared disks.
> The check can be a quick buffered sequential read using the maxBatchSize which should
already be tuned to match the disk transfer rate.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message