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":"http://127.0.0.1:5984/foo";, "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
bad.
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.
Adam
