I am having this error when syncing a connector "source ERROR Killed" What is actually being killed? The sync job pod? If so, how can I make it larger?

"Source ERROR Killed" — What's Happening? Yes, the process being killed is the source container (the connector pod running your source). This is almost always an Out-of-Memory (OOM) kill — Kubernetes terminates the container when it exceeds its memory limit. [Scaling Airbyte] The log line typically looks like:

/airbyte/javabase.sh: line 26: Killed /airbyte/bin/"$APPLICATION" "$@"

How to Increase the Resources There are several ways to configure connector resource requirements, from broadest to most specific: [Configuring Connector Resources] 1. Instance-Wide (affects all jobs) Set these environment variables in your `values.yaml`:

JOB_MAIN_CONTAINER_CPU_REQUEST: "1"
JOB_MAIN_CONTAINER_CPU_LIMIT: "2"
JOB_MAIN_CONTAINER_MEMORY_REQUEST: "2Gi"
JOB_MAIN_CONTAINER_MEMORY_LIMIT: "4Gi"

2. Connector Definition (affects all connectors of that type) Connect to the Airbyte database and run:

-- Step 1: Find the connector definition ID
SELECT * FROM actor_definition WHERE actor_definition.docker_repository LIKE '%<image-name>';

-- Step 2: Update resource requirements
UPDATE actor_definition
SET resource_requirements = '{"jobSpecific": [{"jobType": "sync", "resourceRequirements": {"cpu_limit": "2", "cpu_request": "2", "memory_limit": "2048Mi", "memory_request": "2048Mi"}}]}'
WHERE id = '<id-from-step-1>';

3. Precedence Order Additional Notes • Airbyte's source worker can read up to 10,000 records in memory at once. For sources with large row sizes (e.g. 0.5 MB/row), this can require 5+ GB of RAM. [Scaling Airbyte] • A good starting point is 4 GB memory request/limit and scaling up from there based on your data volume. • There is also a known issue on newer Linux kernels (6.12+) where the JVM ignores pod memory limits and uses host memory instead, causing OOM kills even with sufficient limits set. Downgrading the kernel is the current workaround. [GitHub Issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

Where is the values.yaml file located?

The

values.yaml

file for Airbyte's Helm chart is located at:

charts/v2/airbyte/values.yaml

in the Airbyte platform repository on GitHub. [Values.yaml Reference] However, when customizing your deployment, you don't edit this file directly. Instead, you create your own

values.yaml

override file locally and pass it to Helm during installation or upgrade: [Implementation Guide]

helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml \
  --version 2.x.x

You only need to include the specific values you want to override — there's no need to copy the entire chart

values.yaml

. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai What about this error WARN DefaultDispatcher-worker-3 o.a.p.h.InternalParquetRecordWriter(flushRowGroupToStore):203 Too much memory used: Store Is it the same situation?

I'm sorry, but the knowledge sources do not contain enough information to give a confident answer about this specific warning:

WARN DefaultDispatcher-worker-3 o.a.p.h.InternalParquetRecordWriter(flushRowGroupToStore):203 Too much memory used: Store

This warning appears to originate from the Apache Parquet library (

o.a.p.h

=

org.apache.parquet.hadoop

), which is used by certain destination connectors (e.g. S3, GCS) when writing Parquet files. It suggests the Parquet row group is consuming more memory than expected — but whether this is directly related to the same OOM/resource limit issue as your previous

Killed

error, I cannot say with certainty based on the available knowledge sources. What I'd suggest: • Check if the full logs show an OOM kill (

Exit Code: 137

) shortly after this warning, which would indicate it is related. • Consider opening a GitHub issue or checking the Airbyte community forum for this specific warning, as it may have connector-specific context. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai directly afterwards I've received OOM

In that case, yes — it is the same situation. The Parquet writer warning is a precursor to the OOM kill. The sequence is: 1. The

InternalParquetRecordWriter

warns that it's using too much memory while flushing a row group 2. Memory continues to grow until the container hits its limit 3. Kubernetes kills the container with exit code 137 (OOMKilled) This is consistent with a known issue reported for the S3 source connector with large Parquet files, where the full record-parse step during operations can exhaust available memory. [S3 Source OOM Fix] How to Address It You have two options: 1. Increase the container memory limit As discussed previously, update your resource configuration either instance-wide in `values.yaml`:

global:
  env_vars:
    JOB_MAIN_CONTAINER_MEMORY_REQUEST: "4Gi"
    JOB_MAIN_CONTAINER_MEMORY_LIMIT: "8Gi"

Or at the connector definition level via SQL. [Configuring Connector Resources] 2. If using S3 source with Parquet files A fix was proposed that adds an opt-in

skip_full_check_for_parquet

flag per stream, which skips the full record-parse step to avoid loading large Parquet row groups into memory. [S3 Source OOM Fix] > Note: The trade-off with option 2 is that schema mismatches or corrupt files will only surface at sync time rather than during the check phase. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai So if it was fixed, if I update my S3 destination to a new version it will be resolved?

There are two important clarifications to make here: 1. It's the S3 Source, not Destination The

skip_full_check_for_parquet

fix was applied to the source-s3 connector (version

4.15.3

), not the destination. [S3 Source Changelog] 2. The fix only applies to the CHECK phase The

skip_full_check_for_parquet

flag only skips the full parse during the connection check (CHECK) operation — it does not address OOM errors during actual syncs. [PR #76162] Since you're seeing the

InternalParquetRecordWriter

OOM during a sync, this fix would not resolve your issue. What You Should Do The most reliable solution for your case remains increasing the container memory limit, as the OOM is happening during the actual data sync when Parquet row groups are being written to memory. I'm sorry, but the knowledge sources do not contain enough information to confirm whether there is a specific fix for OOM during Parquet sync writes in the destination connector. I'd recommend: • Checking the S3 destination changelog for any relevant fixes • Opening a GitHub issue if you believe this is a bug • Posting on the Airbyte community forum for further guidance 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai I've manually edited the configmap. Which deployment should I restart?

Based on the knowledge sources, the specific deployment to restart depends on what you've configured: • If you edited resource-related variables (e.g.

JOB_MAIN_CONTAINER_MEMORY_LIMIT

, etc.), you should restart the workload-launcher deployment: [GitHub Issue]

kubectl rollout restart deployment airbyte-abctl-workload-launcher -n airbyte

• If you edited server-related variables, restart the airbyte-server deployment: [GitHub Issue]

kubectl rollout restart deployment airbyte-abctl-server -n airbyte

> Note: The knowledge sources do mention that even after restarting the

workload-launcher

following a ConfigMap edit for resource limits, the replication pods may still default to hardcoded values — this appears to be a known bug in

abctl

v2.0.1. [GitHub Issue] > If that's the case, the recommended workaround is to set the env vars directly on the workload-launcher deployment via

extraEnv

in your

values.yaml

instead of relying on the ConfigMap. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

I have edited this from 2Gi to 20 Gi JOB_MAIN_CONTAINER_MEMORY_LIMIT @kapa.ai

Based on your edit to

JOB_MAIN_CONTAINER_MEMORY_LIMIT

, you should restart the workload-launcher deployment: [GitHub Issue]

kubectl rollout restart deployment airbyte-abctl-workload-launcher -n airbyte

Then verify the environment variable is actually being picked up by the workload-launcher pod:

kubectl exec -n airbyte deploy/airbyte-abctl-workload-launcher -- env | grep JOB_MAIN

> ⚠️ Important caveat: As mentioned previously, there is a known bug where editing the ConfigMap and restarting the workload-launcher may still not propagate the resource limits to the replication pods — they may continue using hardcoded defaults. [GitHub Issue] > If the verify command above shows the correct value but pods still don't respect it, the more reliable workaround is to set it directly on the workload-launcher deployment via `values.yaml`: >

workloadLauncher:
>   extraEnv:
>     - name: JOB_MAIN_CONTAINER_MEMORY_LIMIT
>       value: "20Gi"
>     - name: JOB_MAIN_CONTAINER_MEMORY_REQUEST
>       value: "20Gi"

👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai I don't have this deployment "airbyte-abctl-workload-launcher" I have these: airbyte-connector-builder-server airbyte-cron airbyte-worker airbyte-server airbyte-workload-api-server airbyte-workload-launcher

In that case, the deployment you need to restart is:

kubectl rollout restart deployment airbyte-workload-launcher -n airbyte

Then verify the environment variable is being picked up:

kubectl exec -n airbyte deploy/airbyte-workload-launcher -- env | grep JOB_MAIN

The

airbyte-abctl-

prefix only applies to installations done via

abctl

. Since your deployment is named

airbyte-workload-launcher

, you're likely running a standard Helm deployment. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Okay after restarting, how can I tell what the limit is on the deployment? @kapa.ai

You can verify it two ways: 1. Check the environment variable directly on the pod

kubectl exec -n airbyte deploy/airbyte-workload-launcher -- env | grep JOB_MAIN

This confirms what the workload-launcher process actually sees. 2. Check the logs of a running sync job Once you trigger a sync, Airbyte logs the resource requirements as containers are created. Look for lines like this in the job logs: [Configuring Connector Resources]

platform > [source] image: airbyte/source-s3:x.x.x resources: ResourceRequirements(claims=[], limits={memory=20Gi, cpu=1}, requests={memory=20Gi, cpu=1}, additionalProperties={})

You can view these logs directly in the Airbyte UI by navigating to the job and inspecting the platform logs, or via:

kubectl logs -n airbyte deployment/airbyte-workload-launcher | grep "JOB_MAIN\|memory\|limits"

The second method is the most reliable way to confirm the limits are actually being applied to the replication pods, rather than just being set on the launcher itself. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

I still get the 2Gi memory I think @kapa.ai │ 2026-05-14 161139,052 [default-13] INFO i.a.w.l.p.KubePodClient(launchReplication):100 - [source] image: airbyte/source-declarative-manifest:7.19.1 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=1}, requests={memory=1Gi, cpu=100m}, additionalProperties={}) │ │ 2026-05-14 161139,052 [default-13] INFO i.a.w.l.p.KubePodClient(launchReplication):101 - [destination] image: airbyte/destination-s3:1.9.7 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=1}, requests={memory=2Gi, cpu=100m}, additionalProperties={}) │ │ 2026-05-14 161139,053 [default-13] INFO i.a.w.l.p.KubePodClient(launchReplication):102 - [orchestrator] image: airbyte/container-orchestrator:2.0.1 resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=1}, requests={memory=1Gi, cpu=100m}, additionalProperties={}) │

This confirms the known bug — the ConfigMap edit is being ignored by the workload-launcher, which is still using the hardcoded 2Gi default. [GitHub Issue] The more reliable workaround is to set the values directly on the workload-launcher deployment via your

values.yaml

instead:

workloadLauncher:
  extraEnv:
    - name: JOB_MAIN_CONTAINER_MEMORY_LIMIT
      value: "20Gi"
    - name: JOB_MAIN_CONTAINER_MEMORY_REQUEST
      value: "20Gi"

Then apply it with:

helm upgrade airbyte airbyte/airbyte \
  --namespace airbyte \
  --values ./values.yaml

Then verify it's working by checking the env on the pod:

kubectl exec -n airbyte deploy/airbyte-workload-launcher -- env | grep JOB_MAIN

And trigger a new sync — you should see

memory=20Gi

in the logs instead of

memory=2Gi

. > ⚠️ Note: This is a known open bug affecting Airbyte 2.0.x where resource configurations set via ConfigMap are ignored by the workload-launcher. It has been escalated to the Airbyte engineering team but does not have a fix yet. [GitHub Issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.