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 417FD10A9F for ; Tue, 18 Jun 2013 07:31:19 +0000 (UTC) Received: (qmail 85876 invoked by uid 500); 18 Jun 2013 07:31:16 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 85859 invoked by uid 500); 18 Jun 2013 07:31:16 -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 85844 invoked by uid 99); 18 Jun 2013 07:31:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jun 2013 07:31:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of agundabattula@threatmetrix.com designates 98.129.35.12 as permitted sender) Received: from [98.129.35.12] (HELO server505.appriver.com) (98.129.35.12) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jun 2013 07:31:05 +0000 X-Note-AR-ScanTimeLocal: 6/18/2013 2:30:43 AM X-Policy: GLOBAL - threatmetrix.com X-Primary: agundabattula@threatmetrix.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @threatmetrix.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: agundabattula@threatmetrix.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G319 G320 G321 G322 G326 G327 G338 G434 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 388971132 for user@cassandra.apache.org; Tue, 18 Jun 2013 02:30:43 -0500 Received: from MBX30.exg5.exghost.com ([169.254.1.69]) by HT06.exg5.exghost.com ([98.129.23.206]) with mapi; Tue, 18 Jun 2013 02:30:42 -0500 From: Ananth Gundabattula To: "user@cassandra.apache.org" Date: Tue, 18 Jun 2013 02:30:39 -0500 Subject: What is the effect of reducing the thrift message sizes on GC Thread-Topic: What is the effect of reducing the thrift message sizes on GC Thread-Index: Ac5r9byxO48TZjOhQXmB2J5jpGbRiQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDE649BF118FDagundabattulathreatmetrixcom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CDE649BF118FDagundabattulathreatmetrixcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are currently running on 1.1.10 and planning to migrate to a higher version 1.2.4. The question pertains to tweaking all the knobs to reduce GC related issues ( we have been fighting a lot of really bad GC issues on 1.1.10 and met wit= h little success all the way using 1.1.10) Taking into consideration GC tuning is a black art, I was wondering if we can have some good effect on the GC by tweaking the following settings: *thrift_framed_transport_size_in_mb & thrift_max_message_length_in_mb* * * Our system is a very short column (both in number of columns and data sizes ) tables but having millions/billions of rows in each column family. The ty= pical number of columns in each column family is 4. The typical lookup involves specifying the row key and fetching one column most of the times. The writes are also similar except for one keyspace where the number of columns are 50 but very small data sizes per column. Assuming we can tweak the config values : * * * > thrift_framed_transport_size_in_mb & * * > thrift_max_message_length_in_mb * to lower values in the above context, I was wondering if it helps in the GC being invoked less if the thrift settings reflect our data model reads and = writes ? For example: What is the impact by reducing the above config values on the GC to say 1 mb rather than say 15 or 16 ? Thanks a lot for your inputs and thoughts. Regards, Ananth --_000_CDE649BF118FDagundabattulathreatmetrixcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We are currently running on 1.1.10 and planning to migrate= to a higher
version 1.2.4.

The question pertains to tweaking all= the knobs to reduce GC related issues
( we have been fighting a lot of = really bad GC issues on 1.1.10 and met with little
success all the way u= sing 1.1.10)

Taking into consideration GC tuning is a black art, I w= as wondering if we
can have some good effect on the GC by tweaking the f= ollowing settings:

*thrift_fr= amed_transport_size_in_mb & thrift_max_message_length_in_mb*
*
*Our system is a very short column (both in number of columns and data siz= es
) tables but having millions/billions of rows in each column family. = The typical
number of columns in each column family is 4. The typical lo= okup involves
specifying the row key and fetching one column most of the= times. The
writes are also similar except for one keyspace where the nu= mber of columns
are 50 but very small data sizes per column.

Assu= ming we can tweak the config values :
*
** > thrift_framed_transp= ort_size_in_mb &= amp; *
* > &nbs= p;thrift_max_message_length_in_mb *
=
to lower values in the above context, I was wondering if it helps in th= e GC
being invoked less if the thrift settings reflect our data model re= ads and writes ?

For example: What is the impact by reducing the abo= ve config values on the
GC to say 1 mb rather than say 15 or 16 ?
Thanks a lot for your inputs and thoughts.


Regards,
Ananth
--_000_CDE649BF118FDagundabattulathreatmetrixcom_--