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 >>> >> >> >
