Troubleshooting Quarto memory limit errors in Posit Connect

Abstract

Quarto content fails to render on Posit Connect with out-of-memory or core dump errors when a memory limit is applied, because the Deno runtime that Quarto uses reserves a large block of virtual address space at startup.

Description

Quarto uses Deno, a JavaScript runtime built on the V8 engine. Deno reserves a large block of virtual address space the moment it starts (~70GB), before it does any real work:

Note

This is virtual address space reserved for internal memory management, not physical RAM usage. Actual resident memory consumption is typically a few hundred MB.

When you apply a memory limit to Quarto content on Connect, that limit caps the virtual address space of the process, and Connect refuses the Deno startup reservation. The render fails before it begins, even for a trivial document.

The content logs show one or more errors like the following:

/opt/quarto/1.10.3/bin/quarto: line 210: 1614904 Trace/breakpoint trap (core dumped) "${QUARTO_DENO}" ${QUARTO_ACTION} ${QUARTO_DENO_OPTIONS} ${QUARTO_DENO_EXTRA_OPTIONS} "${QUARTO_TARGET}" "$@"
[connect-quarto] Error: Error running 'quarto inspect': exit status 133

or:

# Fatal process out of memory: Oilpan: CagedHeap reservation

or:

/usr/local/bin/quarto: line 148: 138431 Segmentation fault (core dumped) "${QUARTO_DENO}" ${QUARTO_ACTION} ${QUARTO_DENO_OPTIONS} ${QUARTO_DENO_EXTRA_OPTIONS} "${QUARTO_TARGET}" "$@"

A telltale sign of this issue is that the same content renders without error when no memory limit is applied.

Root cause

Connect enforces memory limits as a hard cap on the virtual address space of a process. This applies to both the per-content Max Memory per Process setting and the server-wide Scheduler.MemoryLimit. Because the Deno runtime reserves far more virtual address space at startup than it ever uses as resident memory, any limit below that reservation (approximately 64 GiB for Quarto 1.6 and later) causes the reservation to fail and the process to abort.

For more detail, see the relevant issues in Quarto and Deno.

Solution

Remove the memory limit on Quarto content

The reliable fix is to set the memory limit for the affected Quarto content to 0 (unlimited).

If the limit is set on the individual content item, open the content settings in the Connect dashboard and clear the Max Memory per Process value.

If the limit is applied server-wide through Scheduler.MemoryLimit and you want to keep a cap on other content types, override the Quarto scheduler types to remove their limit:

/etc/rstudio-connect/rstudio-connect.gcfg

[Scheduler]
MemoryLimit = 16 GB

[Scheduler "quarto-static"]
MemoryLimit = 0

[Scheduler "quarto-shiny"]
MemoryLimit = 0

This caps non-Quarto content at 16 GB while leaving Quarto content unlimited.

For details, see Content process priority and Server process protection in the Connect Admin Guide.

If you’re still having issues, you can reach out to Support by opening a ticket.