hey all, We're running Airbyte 2.1.0 OSS on EKS. T...
# replication-troubleshooting
t
hey all, We're running Airbyte 2.1.0 OSS on EKS. The airbyte-server pod OOMs every ~1 hour with Java heap space at -Xmx8g. Setup: - 16 connections, one with 688 streams (IBM i source with plan explosion) - Server has 4 HikariCP pools + 4 more (8 total in 2.1) - io-executor thread pool grows to 95+ threads per cycle - Every connection triggers applySchemaChange with "Diff is empty" — no actual changes - Upgraded from 2.0.1 where the ConnectionRead.toString() bug was dumping full catalogs into logs — that's fixed in 2.1, but OOM persists Questions: 1. Is there a way to limit the io-executor-thread pool size on the server? (e.g., IO_TASK_EXECUTOR_THREADS or Micronaut config) 2. Can we disable schema propagation discovery for specific connections via API/config without changing the UI setting? 3. Is the server expected to hold all connection catalogs in memory simultaneously, or is this a known leak? 4. Any recommended -Xmx for 16 connections with one 688-stream catalog? 5. Why does 2.1 create 8 HikariCP pools vs 4 in 2.0.1? Logs showing the pattern: applySchemaChange → Diff is empty → Sending notification → (repeat 16x) → OOM
m
Hey Tamir! 1. Yes, you can limit io-executor thread pool via the IO_TASK_EXECUTOR_THREADS env variable. 2. Try disabling the schema propagation via
nonBreakingChangesPreference
Some options are:
ignore
,
disable
,
propagate_columns
, and
propagate_fully
Unsure yet about the other questions as that will require more digging.