You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jim Puls <ji...@nondifferentiable.com> on 2009/07/13 20:29:27 UTC
What would cause CouchDB to start eating up all my memory and CPU?
I'm running CouchDB 0.9.0 to collect a bunch of data and map/reduce it
later. Awesome. Here it is, happily collecting data, being very light
on system resources, indeed:
22383 couchdb 20 0 192m 19m 4096 S 2 3.7 0:12.82
beam.smp
That is, until I request a view. There are perhaps 8000 unindexed
records in this database, and the view server appears to get through
all of them just fine. But as soon as it finishes, CPU and memory both
spike until they exhaust the system:
22383 couchdb 20 0 1052m 453m 2208 S 72 88.4 0:52.65
beam.smp
At this point, all requests to the server time out until I kill it and
restart it. After the restart, everything is fine again until I next
request a view.
Anybody have any ideas? The database is about 600 MB and has about
320000 documents in it. There isn't a record of any exceptions in the
log.
-> jp
Re: What would cause CouchDB to start eating up all my memory and CPU?
Posted by Jim Puls <ji...@nondifferentiable.com>.
On Jul 13, 2009, at 11:29 AM, Jim Puls wrote:
> I'm running CouchDB 0.9.0 to collect a bunch of data and map/reduce
> it later. Awesome. Here it is, happily collecting data, being very
> light on system resources, indeed:
>
> 22383 couchdb 20 0 192m 19m 4096 S 2 3.7 0:12.82
> beam.smp
>
> That is, until I request a view. There are perhaps 8000 unindexed
> records in this database, and the view server appears to get through
> all of them just fine. But as soon as it finishes, CPU and memory
> both spike until they exhaust the system:
>
> 22383 couchdb 20 0 1052m 453m 2208 S 72 88.4 0:52.65
> beam.smp
>
> At this point, all requests to the server time out until I kill it
> and restart it. After the restart, everything is fine again until I
> next request a view.
>
> Anybody have any ideas? The database is about 600 MB and has about
> 320000 documents in it. There isn't a record of any exceptions in
> the log.
Still no exceptions, but blowing away the view index and letting it
reindex from scratch fixed things.
Any suggestions on why this might have happened?
-> jp