I think your problem is likely not the "stuck" hints, but the write
requests in them.
The reason those write requests ended up in the hint file is because
they have failed before. They are likely to fail again when they are
retried if the failure was caused by the write requests themselves
Do you have any performance issues? such as long STW GC pauses or high
p99.9 latency? If not, then you shouldn't tune the GC for the sake of
it. However, if you do have performance issues related to GC, regardless
what is the GC metric you are looking at saying, you will need to
address the
It could also be related to the mutation size of your writes in hint files.
Are you seeing any mutation warnings? if yes, temporarily increasing the
commitlog segment size would help to solve the problem.
Thanks,
On Tue, Nov 16, 2021 at 1:29 PM Bowen Song wrote:
> I think your problem is
Another option to consider is changing your SSTable compression. The default is
LZ4, which is fast for reads and writes but compressed files have a larger disk
footprint. A better alternative might be Zstd, which optimizes for disk
footprint. Here’s the full documentation:
Hi there,
Please don't be worried about under utilization of CPU/RAM as it will
increase with active usage of the data in due course.
However, as pointed out already by other members , you may want to relook
at the hardware itself wherein 5TB per node storage with higher CPU+RAM can
rather be
