[source-github] GitHub Source Connector Consuming Excessive Memory and Failing with OOM / Exit Code 143 During Large Repository Sync

### Connector Name

source-github

### Connector Version

2.1.7

### What step the error happened?

During the sync

### Relevant information

Environment

• Airbyte Version: 2.0.0
• Deployment: Kubernetes (EKS)
• Installation Method: Helm
• Source Connector: GitHub 2.1.7
• Destination Connector: S3 1.9.5
• Destination Storage: Amazon S3

Problem Summary

We are attempting to sync approximately 128 GB of GitHub source data into S3 using the GitHub source connector.

The connector exhibits severe memory consumption issues during replication. The sync repeatedly fails with various memory-related errors including:

• Java Heap Space errors
• Out Of Memory (OOMKilled) events
• Destination container exiting with code 143
• Replication pods consuming extremely large amounts of memory relative to the final output size

What is particularly concerning is that the final synced dataset is only around 1 GB, while the replication job requires hundreds of gigabytes of memory allocation to complete successfully.

Resource Scaling Attempts

We started with the default resource configuration and progressively increased memory over multiple attempts:

Attempt | Memory Allocation
-- | --

Initial | 2 GiB

Attempt 2 | 6 GiB

Attempt 3 | 12 GiB

Attempt 4 | 24 GiB

Attempt 5 | 60 GiB

Attempt 6 | 128 GiB

Despite these increases, the connector continued to fail with different memory-related issues.

Current State

The only way we are able to obtain a successful sync is by:

1. Allocating approximately 128 GiB memory to each container involved in the replication pod.
2. Significantly reducing the number of GitHub streams being synchronized.
3. Syncing only a subset of the available GitHub data.

Even with these restrictions:

• Replication pod memory allocation reaches approximately 128 GiB per container.
• The resulting synchronized data stored in S3 is only about 1 GiB.

This memory-to-output ratio appears abnormal and suggests excessive in-memory buffering or retention somewhere in the source, destination, platform, or logging pipeline.

Errors Observed

Error Type 1

Java heap space errors observed during sync execution.

Example:

java.lang.OutOfMemoryError: Java heap space

Error Type 2

Destination container termination:

Exit Code: 143

Additional Observation: Debug Logging Appears to Increase Memory Pressure

We observed another important behavior:

When Airbyte debug logging is enabled, the GitHub sync fails significantly earlier than when debug logging is disabled.

The failures occur much sooner in the synchronization lifecycle, even before processing the full dataset.

This raises concerns that:

• Connector logs may be accumulating excessively in memory.
• Replication workers may be buffering large volumes of logs.
• Log handling may contribute substantially to memory growth.
• Large GitHub API responses combined with debug logging may amplify memory consumption.

Could the Airbyte logging pipeline be retaining connector logs in memory during large syncs?

Expected Behavior

• GitHub source connector should stream records efficiently without requiring hundreds of gigabytes of memory.
• Memory consumption should be proportional to active processing requirements.
• Large GitHub repository synchronizations should not require 128 GiB allocations to produce approximately 1 GiB of output data.
• Enabling debug logging should not drastically alter memory characteristics or cause premature failures.

Actual Behavior

• Connector repeatedly fails due to memory-related issues.
• Memory requirements continue increasing as larger allocations are provided.
• Successful execution currently requires extremely large memory limits and reduced stream selection.
• Debug logging appears to accelerate failures.

Additional Information Requested

We are looking for help understanding why memory usage grows so significantly during these GitHub syncs and whether this is a known limitation or issue.

This issue is currently blocking our production syncs, so any guidance or assistance would be greatly appreciated.

### Relevant log output

```shell

```

### Contribute

- [ ] Yes, I want to contribute

---
**Internal Tracking:** https://github.com/airbytehq/oncall/issues/12885