Should mention that r776685 translates to `svn up` :) Paul
On Wed, May 20, 2009 at 9:10 AM, Paul Davis <[email protected]> wrote: > Tim, > > Can you try r776685 and see if the problem persists? > > Paul Davis > > On Wed, May 20, 2009 at 8:52 AM, Tim Somers <[email protected]> wrote: >> At first sight, I'm getting the same error once for each running process >> using couchdb, so that makes 5 times. I'll repeat my test though, and check >> if there's something different maybe in the first one. >> >> Tim >> >> >> On Wed, May 20, 2009 at 12:47 PM, Damien Katz <[email protected]> wrote: >> >>> Are there more errors in the log? This error only makes sense to me if >>> something else is restarting, because of a configuration change or because >>> something else must have crashed beforehand. For example, running the test >>> suite restarts components during testing which could cause a crash like >>> this. >>> >>> -Damien >>> >>> >>> On May 20, 2009, at 8:03 AM, Tim Somers wrote: >>> >>> On Wed, May 20, 2009 at 11:57 AM, Paul Davis <[email protected] >>>> >wrote: >>>> >>>> On Wed, May 20, 2009 at 6:15 AM, Tim Somers <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm getting the exact same error: >>>>>> >>>>>> [error] [<0.7002.0>] {error_report,<0.22.0>, >>>>>> {<0.7002.0>,crash_report, >>>>>> [[{pid,<0.7002.0>}, >>>>>> {registered_name,[]}, >>>>>> {error_info, >>>>>> {exit, >>>>>> {timeout, >>>>>> {gen_server,call, >>>>>> [couch_config, >>>>>> >>>>>> {register,#Fun<couch_httpd.9.104562741>,<0.7002.0>}]}}, >>>>>> [{gen_server,call,2}, >>>>>> {couch_httpd,handle_request,4}, >>>>>> {mochiweb_http,headers,5}, >>>>>> {proc_lib,init_p_do_apply,3}]}}, >>>>>> >>>>>> {initial_call,{mochiweb_socket_server,acceptor_loop,['Argument__1']}}, >>>>>> {ancestors, >>>>>> >>>>>> [couch_httpd,couch_secondary_services,couch_server_sup,<0.1.0>]}, >>>>> >>>>>> {messages,[]}, >>>>>> {links,[<0.52.0>,#Port<0.4751>]}, >>>>>> {dictionary,[]}, >>>>>> {trap_exit,false}, >>>>>> {status,running}, >>>>>> {heap_size,2584}, >>>>>> {stack_size,23}, >>>>>> {reductions,1669}], >>>>>> []]}} >>>>>> [error] [<0.52.0>] {error_report,<0.22.0>, >>>>>> {<0.52.0>,std_error, >>>>>> {mochiweb_socket_server,235, >>>>>> {child_error, >>>>>> {timeout, >>>>>> {gen_server,call, >>>>>> [couch_config, >>>>>> {register,#Fun<couch_httpd.9.104562741>, >>>>>> <0.7002.0>}]}}}}}} >>>>>> >>>>>> =ERROR REPORT==== 20-May-2009::12:02:45 === >>>>>> {mochiweb_socket_server,235, >>>>>> {child_error, >>>>>> {timeout, >>>>>> {gen_server,call, >>>>>> [couch_config, >>>>>> {register,#Fun<couch_httpd.9.104562741>,<0.7002.0>}]}}}} >>>>>> >>>>>> >>>>>> >>>>>> although it seems to happen when the system is overloaded. In total, I >>>>>> >>>>> have >>>>> >>>>>> 5 processing constantly reading from and writing to the same couchdb, >>>>>> >>>>> with a >>>>> >>>>>> resulting load average of about 3 and physical memory at it's limit. I >>>>>> >>>>> get >>>>> >>>>>> the impression (though it's hard to reproduce) that this error come at >>>>>> >>>>> the >>>>> >>>>>> moment the system is swapping some ram out to disk, making couchdb run >>>>>> >>>>> into >>>>> >>>>>> some timeout while calculating a view. >>>>>> Couchdb does stay online though, only crashing my app with an unusable >>>>>> result. >>>>>> >>>>>> >>>>> Can you check if couchdb actually stays alive or if it's getting >>>>> respawned by heart? The easiest way to test this is to run couchdb >>>>> with the command line without the init.d script. >>>>> >>>>> Erlang closes the entire VM when it's unable to acquire memory. Ie, if >>>>> malloc returns NULL, then the whole VM closes. The general idea being >>>>> that it'll just rely on heart to be restarted. >>>>> >>>>> Paul Davis >>>>> >>>>> I'm using svn version 776257 >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>> >>>> It stays alive, I always start it from command line. I use the svn version >>>> on port 5985, and the version installed by debian package manager on port >>>> 5984 for comparison. >>>> >>>> Tim >>>> >>> >>> >> >
