[
https://issues.apache.org/jira/browse/COUCHDB-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277082#comment-15277082
]
ASF subversion and git services commented on COUCHDB-2984:
----------------------------------------------------------
Commit d5e0a4a19de99b2c6a91c9de8a1bc120664e36d5 in couchdb-mem3's branch
refs/heads/master from [~banjiewen]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-mem3.git;h=d5e0a4a ]
Reduce frequency of mem3_sync:push/2 calls
In high-throughput scenarios on databases with large q values the
mem3_sync event listener becomes overloaded with messages due to the
poor performance of the shard selection logic.
It's not strictly necessary to sync on every update, but we do need to
be careful not to lose updates by keeping history too naively. This
patch adds a configurable delay and push frequencyto reduce pressure on
the mem3_sync event listener.
COUCHDB-2984
> mem3_sync event listener performance degrades with high q values
> ----------------------------------------------------------------
>
> Key: COUCHDB-2984
> URL: https://issues.apache.org/jira/browse/COUCHDB-2984
> Project: CouchDB
> Issue Type: Improvement
> Reporter: Benjamin Anderson
>
> High throughput applications on databases with high (300+) q values have a
> tendency to cause very poor performance. While I don't fully understand the
> issue at hand, one clear manifestation is in mem3_sync's event listener. With
> high q values, the shard "selection" routine (the <<"shards/",ยท_/binary>>
> head of handle_event/3) will bottleneck on calls to mem3_shards:for_db/1 due
> to the large (tens of KB) shard maps in ETS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
