[
https://issues.apache.org/jira/browse/COUCHDB-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana closed COUCHDB-852.
---------------------------------
Resolution: Fixed
This is a Windows Erlang OTP bug.
A fix (patch) for this issue was already submitted to the Erlang OTP team by
Juhani Ränkimies:
See this thread:
http://erlang.2086793.n4.nabble.com/Fix-appending-to-large-files-gt-4GB-on-Windows-td2829384.html
You might want to grab a Windows installer maintained by Juhani:
http://github.com/juranki/couchdb/downloads
> CouchDB Windows - View building crashing fatally, unable to resume view
> building
> --------------------------------------------------------------------------------
>
> Key: COUCHDB-852
> URL: https://issues.apache.org/jira/browse/COUCHDB-852
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, JavaScript View Server
> Affects Versions: 1.0
> Environment: Windows 7 - 32bit - Erlang R14A (erts-5.8) [source]
> [smp:4:4] [rq:4] [async-threads:0]
> Reporter: Lim Yue Chuan
> Attachments: couchdb.7z, erl_crash.7z
>
>
> I have a DB with about 270,000 documents, inserted via a ruby script.
> Documents inserted fine, I get a working list of documents in the _all_docs
> view, can open an individual document up, etc.
> Tried to generate the appropriate views for the database by hitting a doc via
> futon, memory size/cpu usage stayed sane (35mb, 5-40% on a i5-750) for the
> first 180k documents. Then ballooned up to over 800mb and the view build
> eventually dies.
> [info] [<0.151.0>] checkpointing view update at seq 181904 for gsc_lt2
> _design/mip
> Crash dump was written to: erl_crash.dump
> eheap_alloc: Cannot allocate 373662860 bytes of memory (of type "old_heap").
> (Crash log for the couch/io installer, Mark Hammond's installer dies with a
> similar error message, but eheap_alloc reports "of type "heap"" instead)
> At which point CouchDB completely dies (expected, just mentioning it)
> Restarting CouchDB and trying to resume the view build fails fatally as well,
> with CouchDB reporting enomem errors in mochiweb. At this point, the already
> built view indexes appear to be totally unusable, I am unable to
> clean/compact the views, and I cannot find any way of restarting the build
> process other then by deleting the file holding the view (the md5sum-named
> file).
> Tested on two different harddisks, using both Windows installers (Mark
> Hammond + couch.io). Also further tested on request of benoitc on a vmware
> instance running ubuntu (NOT able to replicate the issue, view generation
> completes fine on the linux VM). Seems to be a Windows issue. VM instance had
> 1GB allocated to it, Machine has 4gb of RAM. Disk space on both tested
> harddisks remained > 20GB free at all times.
> For comparison purposes, memory usage on VM was stable at 5% of system RAM
> (5% of 1GB) throughout the entire view generation.
> The appropriate crash logs are:
> erl_crash.7z - for the first crash.
> couchdb.7z - containing two files:
> couch - start-firstcrash.log - CouchDB log files from startup, through view
> generation, till the first crash
> couch - start-secondcrash.log - CouchDB log files from startup, through
> view generation + first crash, then requerying views, till second (mochiweb)
> crash.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
