Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of cgsmcmlxxv@gmail.com designates
 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF+m3tZSFUB1RPJTk=Ag=YmstfuCU1G3LWQcH-enHU=_1_RXEA@mail.gmail.com>
References: 
 <CAF+m3tZSFUB1RPJTk=Ag=YmstfuCU1G3LWQcH-enHU=_1_RXEA@mail.gmail.com>
Date: Tue, 22 May 2012 11:54:03 +0200
Message-ID: 
 <CAKrexVKx_tq1-ODGXxGqG3FsqCSBh=TsxEQVtUK9Jh+PyCExyg@mail.gmail.com>
Subject: Re: why is couch stealing all my resources?
From: CGS <cgsmcmlxxv@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3033464da342c204c09cff30

--20cf3033464da342c204c09cff30
Content-Type: text/plain; charset=ISO-8859-1

Hi Cory,

There are few general points I would mention:
1. Try to not allow the traffic to increase more than your harddisk
capabilities. That is, in case you notice your traffic is becoming too high
for read/write capabilities of your harddisk, you may want to consider
adding a gateway and more machines to process your data (or at least more
HDD units for parallel processing of your data).
2. Try to avoid oversized databases. That means, it is preferred for you to
create a new database every time your database reaches a certain size. This
recommendation is based on parallel build of your views which, on multicore
CPU's (or multiple CPU's), will use better your computing element(s). Also,
the search, insertion and so on will perform better in the case of smaller
databases.
These points can be easily implemented by using shards in BigCouch, for
example. If you prefer something more dedicated, you can set a gateway
which should manage (by using round-robin, tree or whatever other
algorithm) the users connections. But this last idea requires you to
implement it.

There are other recommendations as well, but I stop to these two because
these are the two that users usually forget to take into account when they
design their projects based on CouchDB.

Of course, your problem may have some other sources, so, more info (OS, CPU
and so on) will help in finding those sources and to add your problem to
the common knowledge.

CGS

PS: As you can notice, I didn't give any numbers here. That's because
everything depends on your systems.

On Tue, May 22, 2012 at 8:34 AM, Cory Zue <czue@dimagi.com> wrote:

> Hi folks,
>
> I have a production app deployed on couchdb and it's been going great for a
> while. However recently it has started to hog lots of the CPU cycles on our
> machine. Also, view rebuilds seem to be happening at a crawl (maybe just
> because the machine is taxed).
>
> We're on couch 1.0.1. The database is about 12 GB. We recently ran
> compaction for the first time. Site traffic has steadily increased
> recently, but not to the point where I would expect it to have such a large
> affect on performance.
>
> Is there any way to see why couch is taking so much resources? I had
> thought to temporarily switch the logging to debug mode and see if there's
> anything interesting there, but curious what other tools/techniques people
> have used to profile couch.
>
> Any general advice on this problem would also be useful.
>
> thanks,
> Cory
>

--20cf3033464da342c204c09cff30--