couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Johnson <>
Subject Re: all_dbs_active error, not sure how to "fix"
Date Sat, 23 Apr 2011 13:31:33 GMT
I'm going by the _stats route, and seeing the open_databases entry --
I do expect that it would reman the same value as max_dbs_open.
However, I would expect when I have quit all clients that might have
existing connections open (which I don't think they did), I still
can't make a request a non-opened database. To me, this means it's not
releasing one of the open databases to open the new database, so
that's why I phrased it that way :)


On Fri, Apr 22, 2011 at 10:22 AM, Paul Davis
<> wrote:
> When you say, doesn't give back open databases, how do you mean? It
> maintains open file descriptors?
> If so, that's intended. The db recycling is basically an LRU cache of
> open databases. The error is generally indicative that a database is
> 'active' when a new request comes in. Active can mean a few things,
> but generally it means that someone is actively connected and using
> the db. Though there's always the chance that we've got a bug that is
> leaking references to the open db so that it might never become
> inactive.
> On Fri, Apr 22, 2011 at 10:45 AM, Jonathan Johnson <> wrote:
>> As I mentioned in my email, even after killing all of my server
>> processes, couch doesn't give back the open databases.
>> I am using Erlang 5.6.5 on 64-bit, so that could very well be the
>> issue. How can I tell if I'm using the version that has the bug -- is
>> it fixed in the current version of Erlang? I believe I'm using erlang
>> installed from yum.
>> Thanks for your help!
>> -Jon
>> On Fri, Apr 22, 2011 at 9:36 AM, Filipe David Manana
>> <> wrote:
>>> On Fri, Apr 22, 2011 at 3:30 PM, Jonathan Johnson <> wrote:
>>>> By doing that, it will increase the number of possible open files
>>>> (although I admit I'm significantly lower than my current limit). My
>>>> point is that I'm never actively connecting to 130 databases, so why
>>>> is couch keeping them open? Shouldn't it recycle databases that hadn't
>>>> been connected to recently?
>>> Yes it should. I dunno, perhaps your application or library is doing
>>> database accesses behind the scenes.
>>> Also, if you change your machine's clock while Couch is running, I
>>> think it might prevent it from properly recycling databases.
>>> Finally, if you're using Erlang OTP R14B02 on a 64 bits machine,
>>> there's a bug in that particular release regarding insertion in
>>> ordered ets tables, which might cause Couch to not do the recycling as
>>> it should.
>>>> -Jon
>>>> On Fri, Apr 22, 2011 at 9:05 AM, Filipe David Manana
>>>> <> wrote:
>>>>> Look at the "max_dbs_open" configuration parameter in the .ini files
>>>>> and increase it to a higher value.
>>>>> On Fri, Apr 22, 2011 at 3:01 PM, Jonathan Johnson <>
>>>>>> I'm running couchdb 1.0.2 on CentOS 5.5. The databases are on an
>>>>>> formatted drive.
>>>>>> I have 209 databases, but they're never truly active at the same
>>>>>> Our stack is written in ruby. The web layer switches between active
>>>>>> databases depending on the url. However, we have 16 web processes,
>>>>>> in theory the maximum number of truly active databases is 16.
>>>>>> We also have a daemon process that loops through a chunk of the
>>>>>> databases periodically. However, it's one thread, and as such also
>>>>>> only truly works with one database at a time.
>>>>>> My understanding is that CouchRest doesn't keep HTTP connections
>>>>>> for multiple requests, but I don't know that for sure. I have even
>>>>>> gone as far as putting in manual garbage collection calls in my daemon
>>>>>> to ensure that any stranded connection objects will be collected.
>>>>>> With all of that, however, I eventually get into a state where I
>>>>>> the all_dbs_active error. It doesn't happen often -- last time was
>>>>>> nearly 3 weeks ago. However, once it gets in the state, restarting
>>>>>> of my clients doesn't release the databases. The only way to recover
>>>>>> is to restart couch.
>>>>>> open_os_files was at 2308 before I restarted it this morning, which
>>>>>> less than the current limit set (4096).
>>>>>> I guess I feel like this is an issue inside of couch because even
if I
>>>>>> quit all of my active server processes that connect to couch, couch
>>>>>> never frees up the open databases. I can hit it one-off from my
>>>>>> browser and still get the error, even though I'm the only active
>>>>>> connection.
>>>>>> Has anyone else seen this? Any ideas of what I can try to prevent
>>>>>> from happening?
>>>>>> Thanks!
>>>>>> -Jon
>>>>> --
>>>>> Filipe David Manana,
>>>>> "Reasonable men adapt themselves to the world.
>>>>>  Unreasonable men adapt the world to themselves.
>>>>>  That's why all progress depends on unreasonable men."
>>> --
>>> Filipe David Manana,
>>> "Reasonable men adapt themselves to the world.
>>>  Unreasonable men adapt the world to themselves.
>>>  That's why all progress depends on unreasonable men."

View raw message