You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Adam Kocoloski (JIRA)" <ji...@apache.org> on 2010/12/08 21:11:01 UTC

[jira] Commented: (COUCHDB-888) out of memory crash when compacting document with lots of edit branches

    [ https://issues.apache.org/jira/browse/COUCHDB-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969461#action_12969461 ] 

Adam Kocoloski commented on COUCHDB-888:
----------------------------------------

The patch rotted with the removal of the 0.9 upgrade code.  Here's the updated version against trunk:

https://github.com/kocolosk/couchdb/commits/888-oome-compaction-conflicts

> 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
>            Assignee: Damien Katz
>             Fix For: 1.0.2, 1.1
>
>         Attachments: 0001-fix-OOME-when-compacting-a-DB-with-many-edit-conflic-v2.patch, 0001-fix-OOME-when-compacting-a-DB-with-many-edit-conflic.patch, 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.