Hey all, wondering if you could provide me some gu...
# troubleshooting
s
Hey all, wondering if you could provide me some guidance towards improving Table API JDBC sink performance, I am running a job which joins a Kafka topic with data stream from two different s3 sources, it seems like the
SinkMaterializer
is very slow for some reason, Flink version 1.16.2. I tried a couple of different things β€’ Increase CPU/memory of task managers β€’ adding
sink.buffer-flush.max-rows
and
sink.buffer-flush.interval
config β€’ mini batching but that did not seem to help
SinkMaterializer
Flink version
1.16.2
I am no way an expert analyzing Flame graph, but this is what I see
Not sure how to interpret that
Any help would be appreciated!
s
SinkMaterializer used a lot of state, so you need to look into optimizing that. Do you use RocksDB for your state backend?
gratitude thank you 1
s
thanks, yes we are using
EmbeddedRocksDBStateBackend
beside this https://nightlies.apache.org/flink/flink-docs-master/docs/ops/state/large_state_tuning/, wondering if you have any other places I can look into for large state optimizations
s
The disks used for RocksDB storage can make a huge difference. You want to obtain the fastest SSD you can get, ideally instance-level (e.g. EBS on AWS can be too slow). Combine that with
state.backend.rocksdb.predefined-options: FLASH_SSD_OPTIMIZED
.
βœ… 1
πŸ™ 1
j
I wonder if SpeedDb would be any faster, we have been benchmarking with kstreams for heavy state and it has shown pretty big improvements.
πŸ‘ 3
s
How easy is it to integrate SpeedDb with Flink?
I want to give it a try for sure, but does not look like there is a great deal of integration information available
s
It should be a drop-in replacement
βœ… 1
j
it’s totes a drop in replacement https://github.com/speedb-io/speedb/releases πŸ˜„ be interested to hear back if you swap
πŸ‘ 2