# Why is Ray Data running out of memory?

**URL:** <https://discuss.ray.io/t/why-is-ray-data-running-out-of-memory/23373>\
**Category:** Ray Data\
**Created:** [December 15, 2025, 7:47pm UTC](https://discuss.ray.io/t/why-is-ray-data-running-out-of-memory/23373 "2025-12-15T19:47:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![btian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ray.io/btian/32/8401_2.png) [@btian](https://discuss.ray.io/u/btian)\
**Post date:** [December 15, 2025, 7:47pm UTC](https://discuss.ray.io/t/why-is-ray-data-running-out-of-memory/23373/1 "2025-12-15T19:47:41Z")

</div>

**1. Severity of the issue: (select one)**  
 Medium: Significantly affects my productivity but can find a workaround.

**2. Environment:**

- Ray version: 2.52.1
- Python version: 3.12.3
- OS: Ubuntu
- Cloud/Infrastructure:
- Other libs/tools (if relevant): PyIceberg 0.10.0

**3. What happened vs. what you expected:**

- Expected: Ray Data should print data quickly
- Actual: OOM even on a machine with 900 GB of RAM

I’m trying to do something really simple.

```python
    from ray.data import read_iceberg
    ds = read_iceberg(
        table_identifier=TABLE,
        catalog_kwargs=CATALOG_ARGS,
        snapshot_id=3554537921535773348,
    )
    ds = ds.select_columns(["id", "vehicle_name", "city", "datasets"]).show(2)

```

But Ray runs out of memory right away, even on a machine with 900GB of ram.

All the selected columns are short strings.

Update: I tried override\_num\_blocks=1 as suggested by RunLLM, still went out of memory.

---

<div class="post-metadata">

**Author:** ![RunLLM](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ray.io/runllm/32/8249_2.png) [@RunLLM](https://discuss.ray.io/u/RunLLM)\
**Post date:** [December 15, 2025, 7:48pm UTC](https://discuss.ray.io/t/why-is-ray-data-running-out-of-memory/23373/2 "2025-12-15T19:48:10Z")

</div>

Ray Data can run out of memory even with large RAM if the dataset is very large, the number of blocks is too small, or the block size is too big. By default, Ray Data tries to fit blocks into memory, but if a block is too large (e.g., due to few blocks or large files), it can cause OOM regardless of the total RAM. This is especially likely if the underlying Iceberg table is large and the parallelism (number of blocks) is not set high enough, causing each block to be massive in memory—even if you select only a few columns of short strings. This is a known issue and can be mitigated by increasing the number of output blocks using the override\_num\_blocks parameter in read\_iceberg, which splits the data into smaller, more manageable chunks for processing and avoids OOM errors. See [Ray Data performance tips](https://github.com/ray-project/ray/blob/releases/2.51.2/doc/source/data/performance-tips.rst) and [read\_iceberg API docs](https://docs.ray.io/en/latest/data/api/doc/ray.data.read_iceberg.html#toctree-checkbox-77).

Try:

```python
ds = read_iceberg(
    table_identifier=TABLE,
    catalog_kwargs=CATALOG_ARGS,
    snapshot_id=3554537921535773348,
    override_num_blocks=1000, # or higher, depending on table size
)
ds = ds.select_columns(["id", "vehicle_name", "city", "datasets"]).show(2)

```

Would you like more detail on how to choose the right number of blocks or further memory tuning?

Sources:

- [Ray Data performance tips](https://github.com/ray-project/ray/blob/releases/2.51.2/doc/source/data/performance-tips.rst)
- [read\_iceberg API docs](https://docs.ray.io/en/latest/data/api/doc/ray.data.read_iceberg.html#toctree-checkbox-77)

Hint: Mention @RunLLM in the post for followups.

---

<div class="post-metadata">

**Author:** ![btian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ray.io/btian/32/8401_2.png) [@btian](https://discuss.ray.io/u/btian)\
**Post date:** [December 23, 2025, 11:21pm UTC](https://discuss.ray.io/t/why-is-ray-data-running-out-of-memory/23373/3 "2025-12-23T23:21:56Z")

</div>

The solution is to set override\_num\_blocks to a large number. I set it to 100\_000, didn’t get OOM.