incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: how to debug a single PUT that is very slow?
Date Mon, 02 Apr 2012 07:00:14 GMT
Any chance to get a script to reproduce?

On the face of it, with you mentioning imagemagick I'm guessing you
have an app layer in front that's proxying through to CouchDB. Given
that nothing like this has ever been reported in the years I've been
hacking on CouchDB I would hazard a guess that the assumed app layer
has a concurrency bug.

Then again I could be completely wrong.

On Mon, Apr 2, 2012 at 1:41 AM, Mark Hahn <mark@hahnca.com> wrote:
> I'm having a problem in a particular situation where a specific put of a
> new document is taking 10 to 20 seconds.  The db is not very loaded down.
>  There are 5 to 25 writes/sec and about 200 reads per second.  I have a db
> watcher that is invoked on every change.
>
> Looking at the log timestamps, the PUT for the new document doesn't even
> register as an [info] line until ten seconds after my app sent the http
> request.  The log just shows normal read and writes during that 10 seconds.
>  No view is being rebuilt nor is there a compaction happening.
>
> I can repeat this any time I want by uploading 18 files from my browser,
> where each of the 18 triggers an invocation of imagemagick thumbnail
> conversion and then adding that thumbnail as an attachment to each of 18
> docs.  The attachments are only about 20 kbytes each.  The doc that is
> trying to be created is unrelated to any of those 18.  The problem just
> happens when I try to create the doc at the same time.
>
> The cpu is not loaded.  Node and the db are only consuming about 15% each
> of the cpu during the episode.
>
> Any idea what could cause this?  What can I do to track the problem down?

Mime
View raw message