couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Damien Katz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-888) out of memory crash when compacting document with lots of edit branches
Date Thu, 16 Sep 2010 20:42:37 GMT

    [ 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.


Mime
View raw message