incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Re: Crash of CouchDB 1.2.x
Date Fri, 02 Mar 2012 03:33:57 GMT
Was your server under heavy load? Did you end up with a bunch of zombie couchjs processes?

I'm a little worried I'm hopping in on something that might be a separate issue, but I was
consistently getting nasty crashes the other day when doing a rush on a _list function,
stacktraces similar to this but in my case the database became completely unresponsive.

1. build-couchdb (1.1.1) on an EC2 t1.micro running Ubuntu
2. Add the '42' file at the path is looking for (a simple way to do this is what's
held up filing JIRA ticket)
3. Run their default rush on a _list function (mine happened to do a fair amount of work,
doing a Markdown conversion and Mustache templating)
4. Around about the 40 concurrent user mark, CouchDB dies a terrible horrible death with a
bunch of zombie couchjs process, all those numbers in the logs and some traces like:


[Tue, 28 Feb 2012 23:47:57 GMT] [error] [<0.712.0>] Uncaught error in HTTP request:

Does this sound related, or separate issue? (Either way, I'm hoping to get a cleaner set of
logs to submit.)


On Mar 1, 2012, at 3:17 AM, Stefan Kögl wrote:
> Hello,
> My experiments to replicate some live data / traffic to a CouchDB
> 1.2.x (running the current 1.2.x branch + the patch from [1]) that
> sparked the indexing speed discussions, did also yield another
> (potential) problem. First sorry for not further reporting back any
> performance measurements, but I didn't yet find the time to run the
> tests on my machines.
> Anyway, I found the following stack traces in my log (after noticing
> that some requests failed and compaction of a view stopped)
> The files starts at the first failed requests. Every request before
> that returned a positiv (ie 2xx) status code. The crash might have
> some "natural" reason (such as timeouts, lack of RAM, etc), but I'm
> not sure how to interpret Erlang stack traces. Can somebody point me
> in the right direction for diagnosing the problem?
> Thanks,
> -- Stefan
> [1]

View raw message