[
https://issues.apache.org/jira/browse/QPID-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406741#comment-17406741
]
Daniil Kirilyuk commented on QPID-8557:
---------------------------------------
To assess flush frequency we use both single-threaded and multithreaded
clients. Sending 10 messages in a singe-threaded client results in 10 flushes:
{noformat}
2021-08-30 13:57:20,518 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,547 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,578 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 5 ms
2021-08-30 13:57:20,605 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,634 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 5 ms
2021-08-30 13:57:20,661 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 2 ms
2021-08-30 13:57:20,690 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,729 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,758 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
2021-08-30 13:57:20,783 DEBUG [Commit-Thread-default]
(o.a.q.s.s.b.CoalescingCommiter$CommitThread) - flushLog completed in 3 ms
{noformat}
Count of flushes in that case scales up with the amount of messages sent.
When sending 10 messages in 10 separates threads, count of flushes varies in
wide range (in our tests from 42 to 79).
Unfortunately in our production environments there are up to several thousands
client connections using all types of clients (JMS, C, python), which could or
could not use transactions (we don't have any control over them).
As the coalescing committer functions in a single thread, controlling BDB log
flush for all connection threads, we would like to make this behavior more
controllable and predictable considering either amount of messages handled or
amount of time since last flush.
CoalescingCommiter calls under the hood
[com.sleepycat.je.Environment.flushLog()|https://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/Environment.html#flushLog-boolean-],
which is described as following: "Writes buffered data to the log, and
optionally performs an fsync to guarantee that data is written to the physical
device. This method is used to make durable, by writing to the log, all
preceding non-transactional write operations, as well as any preceding
transactions that were committed with no-sync durability. If the fsync
parameter is true, it can also be used to flush all logged data to the physical
storage device, by performing an fsync". As BDB transactions are managed via
org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade or
org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade,
CoalescingCommitter is responsible for IO operations, flushing already
committed changes. Or am I seeing it wrong?
> [Broker-J] Batching mode for CoalescingCommitter
> ------------------------------------------------
>
> Key: QPID-8557
> URL: https://issues.apache.org/jira/browse/QPID-8557
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Affects Versions: qpid-java-broker-8.0.5
> Reporter: Daniil Kirilyuk
> Priority: Minor
>
> Although QPID-8547 introduced configurable parameters for
> CoalescingCommitter, BDB log is flushed to disc on every message. That is
> caused by calling future.get() inside of
> org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker
> to wait until CoalescingCommiter calls #CommitThread#processJobs() making the
> operation effectively sync instead of async (every message triggers
> processJobs() and data flush).
> To improve overall performance we suggest to add batching mode for
> CoalescingCommitter, which would consider BDBVirtualHost parameters and flush
> data in chunks of size ${qpid.broker.bdbCommiterNotifyThreshold} or every
> ${qpid.broker.bdbCommiterWaitTimeout} ms (whatever comes first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
