[
https://issues.apache.org/jira/browse/COUCHDB-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910308#action_12910308
]
Damien Katz commented on COUCHDB-888:
-------------------------------------
Adam, perhaps we should limit the # of conflicts allowed, similar to how we
limit total revs? Not sure of implications, but it's always possible to
generate an unlimited # of conflicts that will consume all the memory.
Another option is to keep the rev trees as disk based structures, to avoid
loading them completely into memory at anytime.
Also, a temporary solution here is to purge the conflicts down to a manageable
#.
> out of memory crash when compacting document with lots of edit branches
> -----------------------------------------------------------------------
>
> Key: COUCHDB-888
> URL: https://issues.apache.org/jira/browse/COUCHDB-888
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Reporter: Adam Kocoloski
> Attachments: key_tree_backtrace.txt.gz
>
>
> I have a database which will crash CouchDB if I try to compact it. It causes
> beam.smp to use all the memory on the server. I caught it in the act one
> time and sorted the Erlang processes by memory usage. The process spawned to
> do the compaction turned out to be the culprit. I took a backtrace of the
> process and found that it was mapping a very large revision tree. I have
> reason to believe that the document has a large number (~1000s) of edit
> conflicts.
> I think part of the problem may be that the recursion in
> couch_key_tree:map_simple requires each stack space for every iteration. I'm
> not sure if it's possible to rewrite the algorithm in a more memory-friendly
> way given the current tree structure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
