high read latencies #2635
ltagliamonte-dd
started this conversation in
General
Replies: 1 comment 2 replies
-
@ltagliamonte-dd I cannot tell if it's affected by the compact operation. However, the compact might bring extra disk IO and CPU usage since it needs to read old SSTs and write back when generating the new SST. To confirm this, you can check if the latency is back to normal after the compaction is finished. Also have a check at the disk io/cpu metrics if too high while compaction. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello folks,
we are recording high read latencies, when we write to kvrocks, and I'm looking for suggestions on what to explore/try next.
Background:
We have a job that nightly prepares an updated kvrocks backup, compacts it, and then we deploy this new update to prod where clients reads from it. We don't use replication and the clients only reads from kvrocks.
We wanted to improve this, by constantly updating production, but when we turn the sync on (just a sidecar process that downloads and applies diffs) our P999 latency goes up significantly from ~30ms to 70ms:
All the reads are HGET and all the set are HSET.
We are using latest kvrocks version 2.10.1 and our config looks like:
if we turn off the sync and start from the nightly compacted backup latencies go back to prev values, so we know that writes are afflicting our system and well compacted data also play a big role in read latencies.
Beta Was this translation helpful? Give feedback.
All reactions