Ouch, counters.
Counters in Cassandra have pretty bad performance comparing to
everything else in Cassandra or counters (and their equivalent, such as
integer types) in other mainstream databases, and they often are
inaccurate too. I personally would recommend against the use of counters
in Cassandra. You may need to add more nodes to deal with the peak load
in order to avoid the timeouts if you can't move away from using
counters in Cassandra.
On 13/04/2021 17:45, Joe Obernberger wrote:
Thank you Bowen - I wasn't familiar with PT1M.
I'm doing the following:
update doc.seq set doccount=doccount+? where id=?
Which runs OK.
Immediately following the update, I do:
select doccount from doc.seq where id=?
It is the above statement that is throwing the error under heavy load.
The select also frequently fails with a "No node was available to
execute the query". I wait 50mSec and retry and that typically
works. Sometimes it will retry as many as 15 times before getting a
response, but this PT1M error is new.
Running: nodetool cfstats doc.seq results in:
Total number of tables: 80
----------------
Keyspace : doc
Read Count: 57965255
Read Latency: 0.3294544486347899 ms
Write Count: 384658145
Write Latency: 0.1954830251859089 ms
Pending Flushes: 0
Table: seq
SSTable count: 9
Space used (live): 48344
Space used (total): 48344
Space used by snapshots (total): 0
Off heap memory used (total): 376
SSTable Compression Ratio: 0.6227272727272727
Number of partitions (estimate): 35
Memtable cell count: 6517
Memtable data size: 264
Memtable off heap memory used: 0
Memtable switch count: 154
Local read count: 12900131
Local read latency: NaN ms
Local write count: 15981389
Local write latency: NaN ms
Pending flushes: 0
Percent repaired: 10.69
Bloom filter false positives: 0
Bloom filter false ratio: 0.00000
Bloom filter space used: 168
Bloom filter off heap memory used: 96
Index summary off heap memory used: 168
Compression metadata off heap memory used: 112
Compacted partition minimum bytes: 125
Compacted partition maximum bytes: 149
Compacted partition mean bytes: 149
Average live cells per slice (last five minutes): NaN
Maximum live cells per slice (last five minutes): 0
Average tombstones per slice (last five minutes): NaN
Maximum tombstones per slice (last five minutes): 0
Dropped Mutations: 0
-Joe
On 4/13/2021 12:35 PM, Bowen Song wrote:
The error message is clear, it was a DriverTimeoutException, and it
was because the query timed out after one minute.
/Note: "PT1M" means a period of one minute, see
//https://en.wikipedia.org/wiki/ISO_8601#Durations
<https://en.wikipedia.org/wiki/ISO_8601#Durations>/
If you need help from us to find out why did it happen, you will need
to share a bit more information with us, such as the CQL query and
the table definition.
On 13/04/2021 16:53, Joe Obernberger wrote:
I'm getting this error:
com.datastax.oss.driver.api.core.DriverTimeoutException: Query timed
out after PT1M
but I can't find any documentation on this message. Anyone know
what this means? I'm updating a counter value and then doing a
select from the table. The table that I'm selecting from is very
small <100 rows.
Thank you!
-Joe
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>