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