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>

Reply via email to