│ airbyte-server pod OOM during applySchemaChange with 16 connections on 2.1.0 │ │ The airbyte-server pod (not connectors) crashes with Java heap space OOM every ~1 hour at -Xmx10g. The OOM happens in the server's control plane during schema propagation, not during data syncs. │ │ The crash pattern: server processes 16 connections sequentially, each calling applySchemaChange with "Diff is empty" (no actual changes). The io-executor-thread pool grows to 95+ threads. After all 16 connections are processed, the server OOMs. One connection has 688 streams. │ │ Is there a way to limit the server's io-executor thread pool size or reduce memory usage during schema propagation? Or is the only option to increase server heap?

The knowledge sources do not contain enough information to directly answer your specific question about limiting the

io-executor-thread

pool size in the

airbyte-server

pod or reducing memory usage during schema propagation (

applySchemaChange

) in Airbyte 2.1.0. The knowledge sources do cover several related OOM topics, but none of them address the server control plane OOM during schema propagation specifically. Here's what is relevant from the available information: What the knowledge sources do cover: • Connector-level OOM (JDBC fetchSize, CDC, destination buffering) — these are OOMs in sync job pods, not the server pod itself. • Container orchestrator memory limits being ignored (hardcoded 1Gi) — relevant to replication job pods, not the server. [Container Orchestrator OOM] • Kubernetes resource configuration — for Kubernetes deployments, there are many environment variables for configuring memory limits per job type (

JOB_MAIN_CONTAINER_MEMORY_LIMIT

,

CHECK_JOB_MAIN_CONTAINER_MEMORY_LIMIT

, etc.), but these apply to connector job pods, not the server pod. [Kubernetes OOM workaround] • Unusual RAM usage by airbyte-server — a similar report exists of the server consuming excessive RAM (48GB on a 64GB machine with 300 connections), but no resolution was documented beyond restarting and filing a GitHub issue. [Server RAM usage] What is not covered: • Configuring the

io-executor-thread

pool size in the server • Memory behavior of

applySchemaChange

with large stream counts (688 streams) • Server-specific JVM tuning beyond heap size for schema propagation workloads Suggestions based on available context: Given the lack of specific information, I'd recommend: 1. Filing a GitHub issue at airbytehq/airbyte describing the exact crash pattern, as this appears to be a potential bug in the server's schema propagation logic. 2. Increasing the server heap as a short-term mitigation (you're already at

-Xmx10g

), though the knowledge sources don't confirm this will resolve the root cause. I'm sorry I can't provide a more definitive answer — this specific scenario isn't addressed in the available knowledge sources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.