On Sat, Apr 23, 2011 at 2:38 PM, Jonathan Johnson <[email protected]> wrote: > Great, that does sound like a candidate for what I'm seeing.
Jonathan, A fix was just applied to branch 1.0.x (from where 1.0.3 will be cut from) - https://issues.apache.org/jira/browse/COUCHDB-1138 > > Thank you! > -Jon > > > On Fri, Apr 22, 2011 at 3:49 PM, Damien Katz <[email protected]> wrote: >> 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." >>>> >> >> >> > -- 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."
