You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Ying Bian <yb...@me.com> on 2016/07/04 13:27:48 UTC

Re: Need help on this "badmatch" error of couchdb 2.0

Hi Joah and all,

I would like to let you know that I’ve verified this issue. It is as you expected.

I met this issue again today and the result of `lsof -p <pid> | wc -l` shows 273.
`launchctl limit` showed that the default value of maxfiles per process is 256.

Then I used `launchctl limit maxfiles 10000 unlimited` to increase the limit and 
relaunched couchdb process. It works fine now with more than 273 file descriptors 
opened.

Thanks a lot!

-Ying
 
> On Jun 30, 2016, at 4:31 PM, Ying Bian <yb...@me.com> wrote:
> 
> Hi Joah,
> 
> Thanks for your explanation. I’m looking forward to seeing this error again to verify this. 
> I’ll keep you updated. ;-)
> 
> -Ying
> 
>> On Jun 30, 2016, at 4:16 PM, Joan Touzet <wo...@apache.org> wrote:
>> 
>> Hi Ying,
>> 
>> It's the beam.smp process that is the main couchdb process. The
>> other processes:
>> 
>> epmd: Erlang port mapper daemon, acts as a name server for other
>>       Erlang hosts
>> beam.smp: BEAM, the Erlang Virtual Machine, where couchdb runs
>> cpu_sup: Erlang CPU supervisor process
>> couchjs: The CouchDB view server process, where your Javascript 
>>       map/reduce views execute and are built/maintained. You have
>>       2o f these running.
>> 
>>> Another question, how did you know that the error is EMFILE? I did
>>> not see this even by skimming through the code.
>> 
>> It's right here:
>> 
>>>>> {"status":500,"name":"badmatch","message":"Database encountered an
>>>>> unknown
>>>>> error","reason":"{error,{badmatch,{error,{{badmatch,{error,emfile}},
>> 
>> The {error,emfile} says that the OS has passed up an EMFILE error. I know
>> what this error is from (on Linux) running `man errno`, which lists:
>> 
>>      EMFILE          Too many open files (POSIX.1)
>> 
>> The error code emfile isn't in CouchDB itself because we don't explicitly
>> check for it - as we consider that a configuration error, not a database
>> fault.
>> 
>> All the best,
>> Joan
>