DROP commands become slow/unresponsive when there is a lot of traffic/load on the cluster

[swathimocharla]

Very often we observe that DROP commands become slow/unresponsive when there is a lot of traffic/load on the cluster. Is there a guidance on dimensioning when running KSQL queries when the system has high ongong traffic?

We have tried scaling the cluster when we see increased delays in the response times, but scaling doesn't seem to help and any new additional ksql server that comes up in the cluster takes up all the CPU allocated to it with no improvement in the query response time.

Once we reach this state, every other query becomes unresponsive too, and in turn the entire cluster becomes unusable.

[hrishabhg]

this should have been fixed now. It was due to client telemetry wait time to be 30s for kafka.

[swathimocharla]

hi @hrishabhg , thank you for your response. Please do look at #10501 as well, this query was raised to seek recommendations for dimensioning if such issues occur.

This issue is raised on 0.29 version of ksql, which is the latest.

[Taymindis]

You should pause then terminate the background query first before drop.