Replies: 1 comment
-
Hi, just bumped into same thing - large transaction = large memory usage. Did you have any luck in solving that? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello! I need help in optimizing memory consumption for large changes in a single transaction using flink-oracle-cdc-connector.
Environment:
When updating large number of rows in a single transaction I get the exception:
"ERROR io.debezium.connector.oracle.logminer.LogMinerHelper [] - Mining session stopped due to the java.lang.OutOfMemoryError: Java heap space".
For the table with 20 fields of types (int, float, timestamp, date, string)*4 I could get the results listed in table:
Using SourceFunction created from OracleSource.builder(), startup-mode set to latest-offset,
and self-defined deserializer, where I added log.info to see if the problem starts after debezium/cdc-connector did it work, but Java Heap Space error occurs before the flow gets to the deserialization.
I've tried to provide the next debezium properties, but got no luck:
After some digging, I could find places in code where debezium consume changes from oracle:
Loop to fetch records:
https://github.com/debezium/debezium/blob/1.6/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/logminer/LogMinerStreamingChangeEventSource.java#L154
Inserts/Updates/Deletes records are registered in transaction buffer:
https://github.com/debezium/debezium/blob/1.6/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/logminer/LogMinerQueryResultProcessor.java#L267
Commit records cause all events in transaction buffer to be commited - sent forward to dispatcher, ending in batch handler:
https://github.com/debezium/debezium/blob/1.6/debezium-connector-oracle/src/main/java/io/debezium/connector/oracle/logminer/LogMinerQueryResultProcessor.java#L144
As far as I see, the cause of the problem is that debezium stores all changes locally before the commit of the transaction occurs.
Is there a way to make the connector split a large amount of changes processing for a single transaction? Or maybe any other way to get rid of the large memory consumption problem?
Beta Was this translation helpful? Give feedback.
All reactions