incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: couchdb kills itself
Date Wed, 20 May 2009 13:10:51 GMT
Tim,

Can you try r776685 and see if the problem persists?

Paul Davis

On Wed, May 20, 2009 at 8:52 AM, Tim Somers <somers.tim@gmail.com> 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 <damien@apache.org> 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 <paul.joseph.davis@gmail.com
>>> >wrote:
>>>
>>>  On Wed, May 20, 2009 at 6:15 AM, Tim Somers <somers.tim@gmail.com>
>>>> 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
>>>
>>
>>
>

Mime
View raw message