There is/was a bug where the view indexer kept open a reference to the db
file forever, which was a problem with compaction leaking file handles as
well. Don't have time to look to see what's the status of the bug and fix,
but's likely the source of your problem.


-Damien



On 4/22/11 7:45 AM, "Jonathan Johnson" <[email protected]> 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
><[email protected]> wrote:
>> On Fri, Apr 22, 2011 at 3:30 PM, Jonathan Johnson <[email protected]>
>>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
>>> <[email protected]> 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 <[email protected]>
>>>>wrote:
>>>>> I'm running couchdb 1.0.2 on CentOS 5.5. The databases are on an ext4
>>>>> formatted drive.
>>>>>
>>>>> I have 209 databases, but they're never truly active at the same
>>>>>time.
>>>>> Our stack is written in ruby. The web layer switches between active
>>>>> databases depending on the url. However, we have 16 web processes, so
>>>>> 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
>>>>>alive
>>>>> 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 get
>>>>> 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
>>>>>all
>>>>> 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
>>>>>is
>>>>> 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
>>>>>this
>>>>> from happening?
>>>>>
>>>>> Thanks!
>>>>> -Jon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Filipe David Manana,
>>>> [email protected], [email protected]
>>>>
>>>> "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,
>> [email protected], [email protected]
>>
>> "Reasonable men adapt themselves to the world.
>>  Unreasonable men adapt the world to themselves.
>>  That's why all progress depends on unreasonable men."
>>


Reply via email to