incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peta Bogdan <>
Subject Re: strange crash
Date Mon, 19 Dec 2011 07:50:46 GMT
Thank you all for your answers,

I'll check all the solutions you suggested,

In the meanwhile my couch works very good.

It is very interesting that lucene is able to rise this kind of problems.

Although the indexing in elasticsearch (es) is done only after 20 fields,
the document itself contains ~ 100 fields

and the entire document is retrieved through the river at insert/update
time in couch (although this is configurable, but if one makes a search on

field which is not_analyzed, and not part of the index specification one
could easily make simple searches on that field, as that field is not
broken into tokens).

Anyway the es index update is done almost instantly and works very good and
the document is immediately exposed to search.

The es developers refers to the couch feeding mechanism as an excellent one
and indeed very few db engines have this kind of flexibility/ability.

I have several couch databases (one server instance) running tru es river
and only one of them has 100 fields and about 1.5 million documents.

es and couch work very well together especially because there a re involved
a timeout mechanism which should take care of responsiveness problems.

As far as Erlang/OTP version is concerned, I have developed several
client/server applications in Erlang using OTP platform, and they work well
(after many error-and-trial cycles and a lot of prototyping) on Linux and
UNIX, although a database server is a far more complicated engine than the
ones I develop.

Thank you for your suggestions,


On Fri, Dec 16, 2011 at 4:45 PM, CGS <> wrote:

> Hi,
> Could you try to insert a document manually in Futon without anything else
> running on CouchDB? If yes, then it's not Erlang.
> There is another scenario which may provoke such an error:
> 1. heart sends HB signal to CouchDB.
> 2. CouchDB doesn't answer in time to heart because is busy with
> elasticsearch + insert/update.
> 3. heart kills CouchDB.
> Could you check memory/CPU consumption during your process?
> PS: It wouldn't be the first time when Apache Lucene provokes
> non-responsive CouchDB during the search. So, maybe someone should check
> for the compatibility and usage limits.
> On 12/16/2011 12:50 PM, Peta Bogdan wrote:
>> The box looks like:
>> OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011
>> real mem = 4292550656 (4093MB)
>> avail mem = 4164161536 (3971MB)
>> bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009
>> bios0: Dell Inc. PowerEdge R200
>> cpu0: Intel(R) Xeon(R) CPU E3110 @ 3.00GHz, 3000.58 MHz
>> cpu0:
>> cpu0: 6MB 64b/line 16-way L2 cache
>> cpu1: Intel(R) Xeon(R) CPU E3110 @ 3.00GHz, 3000.21 MHz
>> cpu1:
>> cpu1: 6MB 64b/line 16-way L2 cache
>> I had couchdb on R14B03 but didn't encountered such an issue although is
>> not excluded to appear in this setup also.
>> On Fri, Dec 16, 2011 at 1:39 PM, Dave Cottlehuber<>
>>  wrote:
>>  On 16 December 2011 11:53, Peta Bogdan<>  wrote:
>>>> Thank you Dave,
>>>> The fact that there are three parallel inserts on three different tables
>>> on
>>>> the same server instance could trigger this this behaviour?
>>> No. Either your couch is running on a very small box or there's some
>>> other
>>> issue relating to erlang itself.
>>> If you revert to R14B03 and rebuild couch etc, do you get similar issues?
>>> A+
>>> Dave

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message