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 <[email protected]> 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?
