Is it the accumulated tombstones on a row that make it act as if “wide”? Does cfhistograms count the tombstones or subtract them when reporting on cell-count for rows? (I don’t know.)
-- Jack Krupansky From: Keith Wright Sent: Friday, July 25, 2014 10:24 AM To: user@cassandra.apache.org Cc: Don Jackson Subject: Re: Hot, large row Ha, check out who filed that ticket! Yes I’m aware of it. My hope is that it was mostly addressed in CASSANDRA-6563 so I may upgrade from 2.0.6 to 2.0.9. I’m really just surprised that others are not doing similar actions as I and thus experiencing similar issues. To answer DuyHai’s questions: How many nodes do you have ? And how many distinct user_id roughtly is there ? - 14 nodes with approximately 250 million distinct user_ids For GC activity, in general we see low GC pressure in both Par New and CMS (we see the occasional CMS spike but its usually under 100 ms). When we see a node locked up in CMS GC, its not that anyone GC takes a long time, its just that the consistent nature of them causes the read latency to spike from the usual 3-5 ms up to 35 ms which causes issues for our application. Also Jack Krupansky question is interesting. Even though you limit a request to 5000, if each cell is a big blob or block of text, it mays add up a lot into JVM heap … - The columns values are actually timestamps and thus not variable in length and we cap the length of other columns used in the primary key so I find if VERY unlikely that this is a cause. I will look into the paging option with that native client but from the docs it appears that its enabled by default, right? I greatly appreciate all the help! From: Ken Hancock <ken.hanc...@schange.com> Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org> Date: Friday, July 25, 2014 at 10:06 AM To: "user@cassandra.apache.org" <user@cassandra.apache.org> Cc: Don Jackson <djack...@nanigans.com> Subject: Re: Hot, large row https://issues.apache.org/jira/browse/CASSANDRA-6654
