not really my domain, but one might play with something like unix "nice" - that is, process-priority - but u cannot guess when a process is to be suppresed and when not. unless u put lots of efforts into it.. measuring heart beats, responsiveness etc
svil On Thu, 14 Mar 2013 17:36:56 -0500 Robert Newson <[email protected]> wrote: > Runaway processes are the very devil but the problem is not specific > to CouchDB, there is no CouchDB mechanism for this just as there's no > bash/python/ruby/perl method to limit a while(true){} loop. > > Highly conflicted documents are painful to update and read. I can't do > anything about that today. > > B. > > On 14 March 2013 17:23, Stephen Bartell <[email protected]> wrote: > > Robert, this only works if I don't need to keep those docs around > > anymore. In my case, I want to keep the docs. I don't want to > > keep the conflicts of the docs. Most importantly thought, even if I > > delete all the conflicts on all my docs, I still have the problem > > of _deleted_docs. What I've seen is that only a few docs with a > > few thousand _deleted_docs each will plug up Couch and render > > unusable. You can't get rid of it through natural means. > > > > This is what Riyad was bringing up and what Ive implemented. I > > have a program which replicates from the troubled database _changes > > with the query param style=main_only. This allows me to still have > > the revision tree of the troubled database, but without the > > _deleted_conflicts. I can then wipe out the troubled db, recreate > > it, and replicate the shiny clean data back into it. > > > > This is unnatural and requires custom code to make happen. I can > > live with it until a better solution comes around. > > > > What I'm really concerned about is how couchdb eats all my cpu. > > > > Is there any way to ration the resources that couchdb uses? Like > > tell it not to use more than 50% or something. I think that couch > > eating all the resources on a machine just because its reading > > loads of data is a bug. Is this a reasonable conclusion? > >
