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