Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 77B3810F50 for ; Wed, 5 Feb 2014 22:50:31 +0000 (UTC) Received: (qmail 13493 invoked by uid 500); 5 Feb 2014 22:50:14 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 13437 invoked by uid 500); 5 Feb 2014 22:50:12 -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 13415 invoked by uid 99); 5 Feb 2014 22:50:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 22:50:12 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of srobenal@stanford.edu designates 171.67.219.82 as permitted sender) Received: from [171.67.219.82] (HELO smtp.stanford.edu) (171.67.219.82) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Feb 2014 22:50:07 +0000 Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E0D5341541 for ; Wed, 5 Feb 2014 14:49:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 96E46341517 for ; Wed, 5 Feb 2014 14:49:45 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id vb8so1288078obc.3 for ; Wed, 05 Feb 2014 14:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FOk80Ebx6Hofk2qhvmhviu61+MaQzQAHHVs7LrEb49Q=; b=hCOFpPHGpnNvVlHCmfdLN1WbiqZfnTa2K51Ki0I0Tmccd2pNQsZIjvXSpISXggOCrQ I2oa8ZAUgDC/f3dvS6eKoVDrukZEBxAAfAzNKrBuRI3Ylsw18W5UDK3xugxENzxx3BUE s8zCVQGMAQSEgquLvkNYarlREFT1qr30HvEYfG/DDlh5HfEDhB1+elmZRevX4efoN1mc 1pTly4Vhws63nUg34Fp2A40UP7OPp0Ztv3tmuoORUzDr/+/rc9TXZITtFzaMedaR4dUI tCdJdOpE0J2ixVcfOxEh/d2v1t7VmdPip672xIqHuZi7mK+HOg1uugxBpBtCaWdF3PVo 4qpA== X-Gm-Message-State: ALoCoQnj18wsaEGve4FL3draZmbh3mNtdE2sUp8h1Do7D8J5ADB+AVYaTGjZCtxQQp5VFZEAh9Lbox2yLN2+MLWsdmldUXNFS7jszbtyfrwO2N8RcWt5Hmoulpml9guDJJj1YPcMDA9MwwbSVtmQ7++DUOvZmWhlPBl6mXH4SZ32jvo4EFrUDc0= X-Received: by 10.182.113.195 with SMTP id ja3mr3746570obb.46.1391640584923; Wed, 05 Feb 2014 14:49:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr3746532obb.46.1391640584583; Wed, 05 Feb 2014 14:49:44 -0800 (PST) Received: by 10.76.96.71 with HTTP; Wed, 5 Feb 2014 14:49:44 -0800 (PST) In-Reply-To: <7B81A51C-9ADA-40D5-B74A-FDFFF3410A81@gmail.com> References: <7B81A51C-9ADA-40D5-B74A-FDFFF3410A81@gmail.com> Date: Wed, 5 Feb 2014 14:49:44 -0800 Message-ID: Subject: Re: Periodic rpc_timeout errors on select query From: Steven A Robenalt To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e013d0db0b3124104f1b092e5 X-Virus-Checked: Checked by ClamAV on apache.org --089e013d0db0b3124104f1b092e5 Content-Type: text/plain; charset=ISO-8859-1 Hi Chap, You don't indicate which version of Cassandra and what client side driver you are using, but I have seen the same behavior with Cassandra 2.0.2 and earlier versions of the Java Driver. With Cassandra 2.0.3 and the 2.0.0rc2 driver, my read timeouts are basically nonexistent at my current load levels. Not sure how this applies if you're still on 1.x versions of Cassandra since we moved off of that branch a few months ago. Ditto for the client driver if you're using something other than the Java Driver, or the 1.x version of same. Our problems were due to changes specific to the 2.x versions only. Steve On Wed, Feb 5, 2014 at 2:14 PM, Chap Lovejoy wrote: > Hi, > > We're seeing pretty regular rpc timeout errors on what appear to be simple > queries. We're running a three node cluster under pretty light load. We're > averaging 30-40 writes/sec and about 8 reads/sec according to OpsCenter. > The failures don't seem to be related to any changes in load. A single > query repeated from CQLSH (about once a second or so) will fail > approximately one out of ten times. I do see an increase in the average > read latency around the time of the failure, though it's unclear if that's > from the single failed request or if others are affected. This seems to > happen most on a number of similarly structured tables. One is: > > CREATE TABLE psr ( > inst_id bigint, > prosp_id bigint, > inter_id bigint, > avail text, > comments text, > email text, > first_name text, > last_name text, > m_id text, > m_num text, > phone text, > info blob, > status text, > time timestamp, > PRIMARY KEY ((inst_id, prosp_id), inter_id) > ) WITH CLUSTERING ORDER BY (inter_id DESC) AND > bloom_filter_fp_chance=0.010000 AND > caching='KEYS_ONLY' AND > comment='' AND > dclocal_read_repair_chance=0.000000 AND > gc_grace_seconds=864000 AND > index_interval=128 AND > read_repair_chance=0.100000 AND > replicate_on_write='true' AND > populate_io_cache_on_flush='false' AND > default_time_to_live=0 AND > speculative_retry='99.0PERCENTILE' AND > memtable_flush_period_in_ms=0 AND > compaction={'class': 'SizeTieredCompactionStrategy'} AND > compression={'sstable_compression': 'LZ4Compressor'}; > > I'm executing the query: > SELECT inter_id FROM "psr" WHERE inst_id = 1 AND prosp_id = > 127788649174986752 AND inter_id < 30273563814527279 LIMIT 10000; > > Normally this query returns 32 rows. A total of 413 match the partition > key. > > Here is a trace for a successful run: > | timestamp | source > | source_elapsed > --------------------------------------------------+--------- > -----+---------------+---------------- > execute_cql3_query | 21:52:20,831 | > 10.128.32.141 | 0 > Message received from /10.128.32.141 | 21:52:20,826 | > 10.128.32.140 | 69 > Executing single-partition query on psr | 21:52:20,827 | > 10.128.32.140 | 502 > Acquiring sstable references | 21:52:20,827 | > 10.128.32.140 | 517 > Merging memtable tombstones | 21:52:20,827 | > 10.128.32.140 | 576 > Key cache hit for sstable 54 | 21:52:20,827 | > 10.128.32.140 | 685 > Seeking to partition indexed section in data file | 21:52:20,827 | > 10.128.32.140 | 697 > Skipped 1/2 non-slice-intersecting sstables, | 21:52:20,827 | > 10.128.32.140 | 751 > included 0 due to tombstones > Merging data from memtables and 1 sstables | 21:52:20,827 | > 10.128.32.140 | 773 > Read 32 live and 0 tombstoned cells | 21:52:20,828 | > 10.128.32.140 | 2055 > Enqueuing response to /10.128.32.141 | 21:52:20,829 | > 10.128.32.140 | 2172 > Sending message to /10.128.32.141 | 21:52:20,829 | > 10.128.32.140 | 2341 > Parsing SELECT ... | 21:52:20,831 | > 10.128.32.141 | 105 > Preparing statement | 21:52:20,831 | > 10.128.32.141 | 200 > Sending message to /10.128.32.140 | 21:52:20,831 | > 10.128.32.141 | 492 > Message received from /10.128.32.140 | 21:52:20,836 | > 10.128.32.141 | 5361 > Processing response from /10.128.32.140 | 21:52:20,836 | > 10.128.32.141 | 5534 > Request complete | 21:52:20,837 | > 10.128.32.141 | 6013 > > > And here is on unsuccessful run: > > | timestamp | source > | source_elapsed > ---------------------------------------------------+-------- > ------+---------------+--------------- > execute_cql3_query | 21:56:19,792 | > 10.128.32.141 | 0 > Parsing SELECT ... | 21:56:19,792 | > 10.128.32.141 | 69 > Preparing statement | 21:56:19,792 | > 10.128.32.141 | 160 > Sending message to /10.128.32.137 | 21:56:19,792 | > 10.128.32.141 | 509 > Message received from /10.128.32.141 | 21:56:19,793 | > 10.128.32.137 | 57 > Executing single-partition query on psr | 21:56:19,794 | > 10.128.32.137 | 412 > Acquiring sstable references | 21:56:19,794 | > 10.128.32.137 | 444 > Merging memtable tombstones | 21:56:19,794 | > 10.128.32.137 | 486 > Key cache hit for sstable 59 | 21:56:19,794 | > 10.128.32.137 | 555 > Seeking to partition indexed section in data file | 21:56:19,794 | > 10.128.32.137 | 569 > Key cache hit for sstable 3 | 21:56:19,794 | > 10.128.32.137 | 609 > Seeking to partition indexed section in data file | 21:56:19,794 | > 10.128.32.137 | 621 > Timed out; received 0 of 1 responses | 21:56:24,792 | > 10.128.32.141 | 5000766 > Request complete | 21:56:24,792 | > 10.128.32.141 | 5000888 > > The output of cfstats is: > > SSTable count: 3 > Space used (live), bytes: 606268 > Space used (total), bytes: 612372 > SSTable Compression Ratio: 0.4011882905126778 > Number of keys (estimate): 768 > Memtable cell count: 156 > Memtable data size, bytes: 60451 > Memtable switch count: 34 > Local read count: 1439 > Local read latency: NaN ms > Local write count: 618 > Local write latency: NaN ms > Pending tasks: 0 > Bloom filter false positives: 0 > Bloom filter false ratio: 0.00000 > Bloom filter space used, bytes: 1840 > Compacted partition minimum bytes: 447 > Compacted partition maximum bytes: 20501 > Compacted partition mean bytes: 3478 > Average live cells per slice (last five minutes): 0.0 > Average tombstones per slice (last five minutes): 0.0 > > Is there a problem with the table structure or query that would be causing > these failures? Should we expect timeouts as a regular occurrence in > operation and be prepared to retry every query as needed? > > I'd really appreciate any input you could offer on how to improve this. > These timeouts are causing some rather troublesome errors in our > application. > > Thank you, > Chap > -- Steve Robenalt Software Architect HighWire | Stanford University 425 Broadway St, Redwood City, CA 94063 srobenal@stanford.edu http://highwire.stanford.edu --089e013d0db0b3124104f1b092e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chap,

You don't indicate which v= ersion of Cassandra and what client side driver you are using, but I have s= een the same behavior with Cassandra 2.0.2 and earlier versions of the Java= Driver. With Cassandra 2.0.3 and the 2.0.0rc2 driver, my read timeouts are= basically nonexistent at my current load levels.

Not sure how this applies if you're still on 1.x ve= rsions of Cassandra since we moved off of that branch a few months ago. Dit= to for the client driver if you're using something other than the Java = Driver, or the 1.x version of same. Our problems were due to changes specif= ic to the 2.x versions only.

Steve



On Wed, Feb 5, 2014 at 2:14 PM, Chap= Lovejoy <chaplovejoy@gmail.com> wrote:
Hi,

We're seeing pretty regular rpc timeout errors on what appear to be sim= ple queries. We're running a three node cluster under pretty light load= . We're averaging 30-40 writes/sec and about 8 reads/sec according to O= psCenter. The failures don't seem to be related to any changes in load.= A single query repeated from CQLSH (about once a second or so) will fail a= pproximately one out of ten times. I do see an increase in the average read= latency around the time of the failure, though it's unclear if that= 9;s from the single failed request or if others are affected. This seems to= happen most on a number of similarly structured tables. One is:

CREATE TABLE psr (
=A0 inst_id bigint,
=A0 prosp_id bigint,
=A0 inter_id bigint,
=A0 avail text,
=A0 comments text,
=A0 email text,
=A0 first_name text,
=A0 last_name text,
=A0 m_id text,
=A0 m_num text,
=A0 phone text,
=A0 info blob,
=A0 status text,
=A0 time timestamp,
=A0 PRIMARY KEY ((inst_id, prosp_id), inter_id)
) WITH CLUSTERING ORDER BY (inter_id DESC) AND
=A0 bloom_filter_fp_chance=3D0.010000 AND
=A0 caching=3D'KEYS_ONLY' AND
=A0 comment=3D'' AND
=A0 dclocal_read_repair_chance=3D0.000000 AND
=A0 gc_grace_seconds=3D864000 AND
=A0 index_interval=3D128 AND
=A0 read_repair_chance=3D0.100000 AND
=A0 replicate_on_write=3D'true' AND
=A0 populate_io_cache_on_flush=3D'false' AND
=A0 default_time_to_live=3D0 AND
=A0 speculative_retry=3D'99.0PERCENTILE' AND
=A0 memtable_flush_period_in_ms=3D0 AND
=A0 compaction=3D{'class': 'SizeTieredCompactionStrategy'} AND
=A0 compression=3D{'sstable_compression': 'LZ4Compressor= '};

I'm executing the query:
SELECT inter_id FROM "psr" WHERE inst_id =3D 1 AND prosp_id =3D 1= 27788649174986752 AND inter_id < 30273563814527279 LIMIT 10000;

Normally this query returns 32 rows. A total of 413 match the partition key= .

Here is a trace for a successful run:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 | timestamp =A0 =A0| source =A0 =A0 =A0 =A0| sourc= e_elapsed
--------------------------------------------------+----------= ----+---------------+----------------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0execute_cql3= _query | 21:52:20,831 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0 =A00
=A0 =A0 =A0 =A0 =A0 =A0 =A0Message received from /10.128.32.141 | 21:52:20,826 | 10.128.32.140 = | =A0 =A0 =A0 =A0 =A0 =A0 69
=A0 =A0 =A0 =A0 =A0 Executing single-partition query on psr | 21:52:20,827 = | 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0502
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Acquiring sstable references | 2= 1:52:20,827 | 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0517
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Merging memtable tombstones | 2= 1:52:20,827 | 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0576
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Key cache hit for sstable 54 | 2= 1:52:20,827 | 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0685
Seeking to partition indexed section in data file | 21:52:20,827 | 10.128.3= 2.140 | =A0 =A0 =A0 =A0 =A0 =A0697
=A0 =A0 Skipped 1/2 non-slice-intersecting sstables, =A0| 21:52:20,827 | 10= .128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0751
=A0 =A0 included 0 due to tombstones
=A0 =A0 =A0 =A0Merging data from memtables and 1 sstables | 21:52:20,827 | = 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 =A0773
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Read 32 live and 0 tombstoned cells | 21:52:20,= 828 | 10.128.32.140 | =A0 =A0 =A0 =A0 =A0 2055
=A0 =A0 =A0 =A0 =A0 =A0 =A0Enqueuing response to /10.128.32.141 | 21:52:20,829 | 10.128.32.140 = | =A0 =A0 =A0 =A0 =A0 2172
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sending message to /10.128.32.141 | 21:52:20,829 | 10.128.32.14= 0 | =A0 =A0 =A0 =A0 =A0 2341
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parsing SELECT = ... =A0| 21:52:20,831 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0105
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Preparing state= ment | 21:52:20,831 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0200
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sending message to /10.128.32.140 | 21:52:20,831 | 10.128.32.14= 1 | =A0 =A0 =A0 =A0 =A0 =A0492
=A0 =A0 =A0 =A0 =A0 =A0 =A0Message received from /10.128.32.140 | 21:52:20,836 | 10.128.32.141 = | =A0 =A0 =A0 =A0 =A0 5361
=A0 =A0 =A0 =A0 =A0 Processing response from /10.128.32.140 | 21:52:20,836 | 10.128.32.141 | = =A0 =A0 =A0 =A0 =A0 5534
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Request = complete | 21:52:20,837 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 6013


And here is on unsuccessful run:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0| timestamp =A0 =A0| source =A0 =A0 =A0 =A0| so= urce_elapsed
---------------------------------------------------+---------= -----+---------------+---------------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 execute_cql= 3_query | 21:56:19,792 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0 =A00
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Parsing SELE= CT ... =A0| 21:56:19,792 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0 69
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Preparing st= atement | 21:56:19,792 | 10.128.32.141 | =A0 =A0 =A0 =A0 =A0 =A0160
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sending message to /10.128.32.137 | 21:56:19,792 | 10.128.32= .141 | =A0 =A0 =A0 =A0 =A0 =A0509
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Message received from /10.128.32.141 | 21:56:19,793 | 10.128.32.137= | =A0 =A0 =A0 =A0 =A0 =A0 57
=A0 =A0 =A0 =A0 =A0 =A0Executing single-partition query on psr | 21:56:19,7= 94 | 10.128.32.137 | =A0 =A0 =A0 =A0 =A0 =A0412
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Acquiring sstable references | = 21:56:19,794 | 10.128.32.137 | =A0 =A0 =A0 =A0 =A0 =A0444
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Merging memtable tombstones = | 21:56:19,794 | 10.128.32.137 | =A0 =A0 =A0 =A0 =A0 =A0486
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key cache hit for sstable 59 | = 21:56:19,794 | 10.128.32.137 | =A0 =A0 =A0 =A0 =A0 =A0555
=A0Seeking to partition indexed section in data file | 21:56:19,794 | 10.12= 8.32.137 | =A0 =A0 =A0 =A0 =A0 =A0569
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Key cache hit for sstable 3 = | 21:56:19,794 | 10.128.32.137 | =A0 =A0 =A0 =A0 =A0 =A0609
=A0Seeking to partition indexed section in data file | 21:56:19,794 | 10.12= 8.32.137 | =A0 =A0 =A0 =A0 =A0 =A0621
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Timed out; received 0 of 1 responses | 21:56:24= ,792 | 10.128.32.141 | =A0 =A0 =A0 =A05000766
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Request= complete | 21:56:24,792 | 10.128.32.141 | =A0 =A0 =A0 =A05000888

The output of cfstats is:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SSTable count: 3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Space used (live), bytes: 606268
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Space used (total), bytes: 612372
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SSTable Compression Ratio: 0.40118829051267= 78
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Number of keys (estimate): 768
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Memtable cell count: 156
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Memtable data size, bytes: 60451
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Memtable switch count: 34
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Local read count: 1439
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Local read latency: NaN ms
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Local write count: 618
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Local write latency: NaN ms
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pending tasks: 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bloom filter false positives: 0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bloom filter false ratio: 0.00000
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bloom filter space used, bytes: 1840
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Compacted partition minimum bytes: 447
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Compacted partition maximum bytes: 20501 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Compacted partition mean bytes: 3478
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Average live cells per slice (last five min= utes): 0.0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Average tombstones per slice (last five min= utes): 0.0

Is there a problem with the table structure or query that would be causing = these failures? Should we expect timeouts as a regular occurrence in operat= ion and be prepared to retry every query as needed?

I'd really appreciate any input you could offer on how to improve this.= These timeouts are causing some rather troublesome errors in our applicati= on.

Thank you,
Chap



--
Steve Robenalt
Software Architect
HighWire | Stanford University=A0=
425 Broadway St, Redwoo= d City, CA 94063=A0

srobenal@s= tanford.edu
--089e013d0db0b3124104f1b092e5--