headers
mike | 1 Jan 2011 15:47
Picon
Favicon

Re: Compact not completing

I did the same with the tagged 1.0.1. Attached is
the error produced. My responses are below:

Citando Robert Newson <robert.newson@...>:

> Some more info would help here.
>
> 1) How far did compaction get?
It gets to seq 96282148 of 109105202 ie: 88%

> 2) Do you have enough spare disk space?
Yes I have lots of free space :-)

> 3) What commit of 1.0.x were you running before you moved to 08d71849?
I was using Dec 13 852fa047. Before that something at least a month old.

> B.
>
> On Fri, Dec 31, 2010 at 3:55 PM, Robert Newson   
> <robert.newson@...> wrote:
>> Can you try this with a tagged release like 1.0.1?
>>
>> On Fri, Dec 31, 2010 at 3:38 PM,  <mike@...> wrote:
>>> Hello,
>>>
>>> Hoping for some guidance. I have a rather large (295Gb) database that was
>>> created
>>> running 1.0.x and I am pretty certain that there is no corruption - It has
>>> always
>>> been on a clean ZFS volume.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wayne Conrad | 1 Jan 2011 23:18
Gravatar

Multiple couchdb servers, same box

Hello.  I'm trying to start a second couchdb server on a box which 
already has one running, but the second one will not accept 
connections.  However, if I stop the first one before starting the 
second one, it _does_ accept connections.

For the second instance, I'm tacking on another .ini file to override 
the obvious things: port, log location, database directory, &c.  I'll 
bet I missed something.  What should I look for?

Versions:

     Debian Testing ("squeeze")
     Couchdb 0.11.0-2.3 (the -2.3 bit is Debian bookkeeping)
     When I run erl, it says: Erlang R14A (erts-5.8) [source] [smp:2:2] 
[rq:2] [async-threads:0] [kernel-poll:false]

The command line to start the second couchdb:

     sudo couchdb -a /tmp/second.ini

The contents of /tmp/second.ini

     [couchdb]
     database_dir = /tmp/second
     view_index_dir = /tmp/second

     [httpd]
     port = 1024
     bind_address = 127.0.0.1
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randall Leeds | 1 Jan 2011 23:37
Picon
Gravatar

Re: Multiple couchdb servers, same box

Use a different pid file. I think the option is -p on the command line.
On Jan 1, 2011 5:20 PM, "Wayne Conrad" <wconrad@...> wrote:
> Hello. I'm trying to start a second couchdb server on a box which
> already has one running, but the second one will not accept
> connections. However, if I stop the first one before starting the
> second one, it _does_ accept connections.
>
> For the second instance, I'm tacking on another .ini file to override
> the obvious things: port, log location, database directory, &c. I'll
> bet I missed something. What should I look for?
>
> Versions:
>
> Debian Testing ("squeeze")
> Couchdb 0.11.0-2.3 (the -2.3 bit is Debian bookkeeping)
> When I run erl, it says: Erlang R14A (erts-5.8) [source] [smp:2:2]
> [rq:2] [async-threads:0] [kernel-poll:false]
>
> The command line to start the second couchdb:
>
> sudo couchdb -a /tmp/second.ini
>
> The contents of /tmp/second.ini
>
> [couchdb]
> database_dir = /tmp/second
> view_index_dir = /tmp/second
>
> [httpd]
> port = 1024
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wayne Conrad | 2 Jan 2011 01:01
Gravatar

Re: Multiple couchdb servers, same box

Aha, that's it.  Thanks!

On 01/01/2011 03:37 PM, Randall Leeds wrote:
> Use a different pid file. I think the option is -p on the command line.
> On Jan 1, 2011 5:20 PM, "Wayne Conrad"<wconrad@...>  wrote:
>    
>> Hello. I'm trying to start a second couchdb server on a box which
>> already has one running, but the second one will not accept
>> connections. However, if I stop the first one before starting the
>> second one, it _does_ accept connections.
>>
Permalink | Reply | 0 comments |
headers
Adam Kocoloski | 2 Jan 2011 01:55
Picon
Favicon
Gravatar

Re: Compact not completing

Ok, so this is the same error both times.  As far as I can tell it indicates that the seq_tree and the id_tree
indexes are out of sync; the seq_tree contains some record that isn't present in the id_tree.  That's never
supposed to happen, so the compactor crashes instead of trying to deal with the 'not_found' result when it
does a lookup on the missing entry in the id_tree.

I suspect that the _purge code is to blame, since deletions don't actually remove entries from these
indexes.  One thing you might try:

1) Query _changes starting from 96281148 (1000 less than the last status update) and grab the next 1000 rows

2) Figure out which of those entries are missing from the id tree, e.g. lookup the document and see if the
response is {"not_found":"missing"}.  You could also try using include_docs=true on the _changes feed
to accomplish the same.

3) Once you've identified the problematic IDs, try creating them again.  You might end up introducing
duplicates in the _changes feed, but if you do there's a procedure to fix that.

That's the simplest solution I can think of.  Purging them again won't work because the first thing _purge
does is lookup the Ids in the id_tree.  Regards,

Adam

On Jan 1, 2011, at 9:47 AM, mike@... wrote:

> I did the same with the tagged 1.0.1. Attached is
> the error produced. My responses are below:
> 
> Citando Robert Newson <robert.newson@...>:
> 
>> Some more info would help here.
(Continue reading)

Permalink | Reply | 2 comments |
headers
mike | 2 Jan 2011 06:43
Picon
Favicon

Re: Compact not completing

Adam,

Thanks for an excellent explanation. It was easy to find the culprit:

curl -s  
'172.17.17.3:5984/iris/_changes?since=96281148&limit=1000&include_docs=true' |  
grep -v time
{"results":[
{"seq":96281622,"id":"1292252400F7005","changes":[{"rev":"2-d94be4c93931a35524b3f34b9de41a11"}],"deleted":true,"doc":{"_id":"1292252400F7005","_rev":"2-d94be4c93931a35524b3f34b9de41a11","_deleted":true}},
],
"last_seq":96282306}

The problem I have is that the document exists with different rev and is not
deleted:

curl -s '172.17.17.3:5984/iris/1292252400F7005'
{"_id":"1292252400F7005","_rev":"1-74a74942107db308d42864e50c1517aa", ....

I deleted the document and inserted it again but the changes feed remains
the same as above - I presume the compact will still fail as before.

Anything else I can do ? (I guess I could hack copy_docs so that not_found
is not 'fatal').

I am compacting regardless, maybe it'll pass.....

Regards,

Mike
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Freeman | 2 Jan 2011 12:52

Document versioning with multiple documents

I'm trying to implement document versioning using a variation of the
method described under 'Multiple Documents' here:
http://blog.couchone.com/post/632718824/simple-document-versioning-with-couchdb

(I'd like to have been able to use the 'attachPrevRev' approach, but
unfortunately that doesn't seem to allow me to setup a view that lists
all the revisions for a document - i.e., I can't access the older
revisions (attachments) from the view server.)

I have documents like this:

{_id: '1', type: 'page'}
{_id: '2', type: 'page_revision', page: '1', created_at: [2011, 1, 1,
11, 28, 0], content: 'First revision of first page.'}
{_id: '3', type: 'page'}
{_id: '4', type: 'page_revision', page: '3', created_at: [2011, 1, 1,
11, 29, 0], content: 'First revision of second page.'}
{_id: '5', type: 'page_revision', page: '3', created_at: [2011, 1, 1,
11, 30, 0], content: 'Second revision of second page.'}

My view then has a map function:

function(doc) {
  if (doc.type == 'page_revision') {
    emit([doc.page, doc.created_at], doc);
  }
}

Which emits the following keys:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mahesh Paolini-Subramanya | 2 Jan 2011 18:22
Favicon

Re: Multiple couchjs processes being spawned

Wow - wierdness here.  I'm running 1.0.1, and have noticed the same thing
happening.  The specific (and very replicable - for me at least) scenario is
as follows
- I've got around a thousand dbs, each with around 50K documents, and each
with about 5 (javascript) design documents.
- I clobber all the views, and remotely (LWP::UserAgent) compact the view
($db/_compact/$design)

On Mon, Sep 7, 2009 at 12:18 AM, Paul Davis <paul.joseph.davis@...>wrote:

> Another random thought, after your clients have been running a bit, an
> easy way to check why type of stuff is going on with sockets is:
>
> $ netstat -ap tcp
>
> If your apps have periods of high turnover, check the sockets to see
> if you have lots of them in TIME_WAIT state.
>
> Paul
>
> On Sun, Sep 6, 2009 at 11:39 PM, Arun Thampi<arun.thampi@...> wrote:
> > Thanks Paul for the quick response. I'll poke around further to see if
> there
> > is anything amiss and will keep the list posted.
> > Cheers,
> > Arun
> >
> > On Mon, Sep 7, 2009 at 11:24 AM, Paul Davis <paul.joseph.davis@...
> >wrote:
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mahesh Paolini-Subramanya | 2 Jan 2011 18:25
Favicon

Re: Multiple couchjs processes being spawned

Sorry - apologies - hit Send by accident :-(

Wow - wierdness here.  I'm running 1.0.1, and have noticed the same thing
happening.  The specific (and very replicable - for me at least) scenario is
as follows
- I've got around a thousand dbs, each with around 50K documents, and each
with about 5 (javascript) design documents.
- I clobber all the views, and remotely (LWP::UserAgent) compact the view
($db/_compact/$design)
- THe compaction of the design document results in the design exactly being
generate (this is good_
- The compaction also leave a couchjs process just lying around (this would
be bad)
- After a few thousand couchjs processes, couchdb just chokes.

Any ideas? This related in any way to the process issues in BigCouch (Jira
-901)?

cheers

On Mon, Sep 7, 2009 at 12:18 AM, Paul Davis <paul.joseph.davis@...>wrote:

> Another random thought, after your clients have been running a bit, an
> easy way to check why type of stuff is going on with sockets is:
>
> $ netstat -ap tcp
>
> If your apps have periods of high turnover, check the sockets to see
> if you have lots of them in TIME_WAIT state.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Adam Kocoloski | 2 Jan 2011 22:53
Picon
Favicon
Gravatar

Re: Multiple couchjs processes being spawned

These reports do sound suspiciously like the problems described in COUCHDB-901 that caused us to rewrite
the OS process management in BigCouch.  Mahesh, yours is the first report I've heard that specifically
implicated view compaction.  That's significant.  I didn't understand what you meant by "clobber all the
views", though.

I'll poke around and see if I can devise a scenario where the OS process would not be released after view
compaction.  In my experience the internal ets tables maintained in CouchDB to track OS processes got
out-of-sync - one table would report 1000 available processes, while another table would claim only 2.  Best,

Adam

On Jan 2, 2011, at 12:25 PM, Mahesh Paolini-Subramanya wrote:

> Sorry - apologies - hit Send by accident :-(
> 
> Wow - wierdness here.  I'm running 1.0.1, and have noticed the same thing
> happening.  The specific (and very replicable - for me at least) scenario is
> as follows
> - I've got around a thousand dbs, each with around 50K documents, and each
> with about 5 (javascript) design documents.
> - I clobber all the views, and remotely (LWP::UserAgent) compact the view
> ($db/_compact/$design)
> - THe compaction of the design document results in the design exactly being
> generate (this is good_
> - The compaction also leave a couchjs process just lying around (this would
> be bad)
> - After a few thousand couchjs processes, couchdb just chokes.
> 
> Any ideas? This related in any way to the process issues in BigCouch (Jira
> -901)?
(Continue reading)

Permalink | Reply | 6 comments |

Gmane