Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 328A4CAFA for ; Fri, 11 May 2012 01:42:54 +0000 (UTC) Received: (qmail 46676 invoked by uid 500); 11 May 2012 01:42:53 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 46636 invoked by uid 500); 11 May 2012 01:42:53 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 46627 invoked by uid 99); 11 May 2012 01:42:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 01:42:53 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FROM_12LTRDOM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,TO_NO_BRKTS_PCNT X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.214.180] (HELO mail-ob0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2012 01:42:45 +0000 Received: by obbup16 with SMTP id up16so3448757obb.11 for ; Thu, 10 May 2012 18:42:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=84ND9H5j8M0pq7/7opjjjmtbWNqdDir8fzZ2o7TB7Aw=; b=Yqt4jGm6x2zo0ACW38ekcSy7LsYzDhf6cKm2kxJ9rrmVtZLajyWzFPcw32PulHxXDb YFO9fHtqZ6IhZbjKScH0HriYRxii1G/s01tqjSU+htPKRSZJ7aIKnJDRhTYX94H5Fg5d 30Ydv6yNNJEe2CpLa/q7zVSlWSNavIr9k/hatXmWSkmpSlduEmWKRCd9Gh/WfNyPkpnb vOlKDcSQOIhe9UCwQ/kOI/FqL7K1/joGQaRGWcl71KGAhBRh98UPBsOJf7KUaTIUicja jBNf9U5UDlApTG8K62IqfDRa7NpDLbiczecQnRZcc9kNT3JRScOm1DZJre0QDkp0M3FW wIVA== Received: by 10.182.172.100 with SMTP id bb4mr9023710obc.22.1336700544754; Thu, 10 May 2012 18:42:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.16.37 with HTTP; Thu, 10 May 2012 18:42:04 -0700 (PDT) X-Originating-IP: [188.82.193.216] From: Marco Monteiro Date: Fri, 11 May 2012 02:42:04 +0100 Message-ID: Subject: CouchDB freezes To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=e89a8f83a1dd2424cf04bfb8d95a X-Gm-Message-State: ALoCoQloWjzYBUKkgc3oqr23FadaqSDauVA+jrsJc9Jwr3qQ/ffgE8juYMjfRDYJbAj9pJVYwAtM X-Virus-Checked: Checked by ClamAV on apache.org --e89a8f83a1dd2424cf04bfb8d95a Content-Type: text/plain; charset=ISO-8859-1 Hello! I'm running a load test on CouchDB. I have a cluster of 8 node.js servers writing to CouchDB. They write about 30000 documents per minute (500 per second). There are multiple concurrent requests form each server. There are no updates: documents are created and not modified. I first tried CouchDB 1.1.1 from Debian 6.4 apt repo. After a few minutes, CouchDB starts freezing for a period of 1 to 3 seconds about every 10 seconds. It keeps this behaviour for some time and eventually it starts freezing more frequently and for longer periods. When the database has about 1.5 million documents, couchdb is freezing for more than 5 seconds each time. I then tried CouchDB 1.2, from build-couch. The freezes happen with it also, but the behavior is much worse: in less than one minute it's freezing for 5 seconds or more, and it spends more time not doing anything than working. When testing with 1.1.1 I was writing only to one database. With 1.2 I tried with one database and then with multiple databases but the problem was exactly the same. The documents have about 10 properties, only numbers or string and the strings are small (about 20 chars each). The document IDs are generated in the app and have the format - When CouchDB freezes, it's processor use (from top) goes to zero. It does not reply to read or write requests. The disk does not seem to be the problem as iostat reports near 0% utilization. CPU is mostly idle, and from the 16 GB of RAM, some of it is free and is not even used to cache disk. There are no error message in Couchdb log. I tried this in two different machines and the problem is the same in both. I did not change anything in the configuration files expect changing the database dir to use a RAID partition. Anyone has any idea of what the problem could be? Any help solving this issue is greatly appreciated. Thanks, Marco --e89a8f83a1dd2424cf04bfb8d95a--