Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 5674 invoked from network); 14 Apr 2011 07:10:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Apr 2011 07:10:44 -0000 Received: (qmail 72337 invoked by uid 500); 14 Apr 2011 07:10:39 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 72313 invoked by uid 500); 14 Apr 2011 07:10:39 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 72296 invoked by uid 500); 14 Apr 2011 07:10:39 -0000 Delivered-To: apmail-incubator-cassandra-user@incubator.apache.org Received: (qmail 72292 invoked by uid 99); 14 Apr 2011 07:10:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 07:10:39 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.47] (HELO mail-pz0-f47.google.com) (209.85.210.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 07:10:31 +0000 Received: by pzk35 with SMTP id 35so517164pzk.6 for ; Thu, 14 Apr 2011 00:10:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.11.166 with SMTP id r6mr264327pbb.497.1302765010126; Thu, 14 Apr 2011 00:10:10 -0700 (PDT) Sender: scode@scode.org Received: by 10.68.59.231 with HTTP; Thu, 14 Apr 2011 00:10:09 -0700 (PDT) X-Originating-IP: [90.232.70.54] In-Reply-To: <1302736223485-6270942.post@n2.nabble.com> References: <1302641755259-6266726.post@n2.nabble.com> <1302653804466-6267234.post@n2.nabble.com> <1302671874121-6267728.post@n2.nabble.com> <1302711621627-6269655.post@n2.nabble.com> <1302721345270-6270244.post@n2.nabble.com> <1302736223485-6270942.post@n2.nabble.com> Date: Thu, 14 Apr 2011 09:10:09 +0200 X-Google-Sender-Auth: 0AntLUxP3DliqK1f0e2NvVRhKho Message-ID: Subject: Re: flush_largest_memtables_at messages in 7.4 From: Peter Schuller To: user@cassandra.apache.org Cc: mcasandra , cassandra-user@incubator.apache.org Content-Type: text/plain; charset=UTF-8 > Actually when I run 2 stress clients in parallel I see Read Latency stay the > same. I wonder if cassandra is reporting accurate nos. Or you're just bottlenecking on something else. Are you running the extra stress client on different machines for example, so that the client isn't just saturating? > I understand your analogy but for some reason I don't see that happening > with the results I am seeing with multiple stress clients running. So I am > just confused where the real bottleneck is. If your queue size to your device is consistently high (you were mentioning numbers in the ~100 range), you're saturating on disk, periods. Unless your disk is a 500 drive RAID volume and 100 requests represents 1/5 of capacity... (If you have a raid volume with a few disks or an ssd, you want to switch to the noop or deadline scheduler btw.) -- / Peter Schuller