incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Timeout Error when trying to access views + Indexing problems
Date Tue, 06 Oct 2009 19:13:21 GMT
On Oct 6, 2009, at 2:46 AM, Glenn Rempe wrote:

> Adam, I tried your suggestion to attempt to open the index file in
> interactive mode.  I was able to start CouchDB in interactive mode,  
> and the
> 'couch_file:open' command return ok instantly, but the
> 'couch_file:read_header(Fd).' provided no output for about 15 min  
> and I
> eventually aborted it.  Should it ever take that long?  What output  
> should I
> expect to see?

That's exactly the problem behavior I saw.  I don't remember what the  
expected output of couch_file:read_header(Fd) is, but it should return  
almost instantaneously.  This worries me.

On Oct 6, 2009, at 12:09 PM, Glenn Rempe wrote:

> Sorry, I think one of my questions was not clear.  I meant:  If I
> 'replicated' the DB from its current location to a new DB name on  
> the same
> host would that do the scan for malformed records (which wasn't run  
> on the
> beginnning of this DB since it was started on 0.9.1) and would  
> indexing
> happen incrementally during 'replication' if I setup that ruby index  
> script
> so I can avoid these huge indexing events which take a god-awful  
> long time
> before failing?

Replicating to a new DB would do the check only if the source or  
target is "remote", e.g.

{"source":"", "target":"bar"}

I'm guessing a mal-formed document isn't the source of your problem,  
but if it is this replication would show you exactly which document is  

> There has *got* to be a way to bump up the logging level on all of  
> these
> processes.  Is that single line in the log about restarting CouchDB  
> really
> all I get?  With no indication at ALL of WHY its restarted (and  
> apparently
> killed my index processing in the process, or is that the indexing  
> process
> has died forcing a restart?  The logs just don't seem to want to  
> give that
> info up.) ?  Am I missing something?  I NEED logging data to find  
> out what
> the hell is going on here.  The silent death treatment is driving me  
> nuts.

TMI logging doesn't really exist, no one uses that level internally.   
I agree with Paul here, the lack of error messages indicates an  
instant VM death.  The most common way to cause that is by running out  
of memory, but view indexing is not supposed to use a large amount of  
memory at all.


View raw message