--max-old-space-size=8192to buy some time while you rethink your approach.
In a generational garbage collector, like the one used by V8, the heap is usually divided in two major spaces: a young generation (new-space in V8) and an old generation (old-space in V8).
This division comes from the observation that only around 20% of the objects that are allocated are long-lived, the rest are used only a few times and can be deallocated shortly after creation. On the other hand, objects that survive and are moved to the old generation are likely to stay there for the duration of the execution.
The young generation is small (around
consequently fast to scan and garbage collect. The few
objects that survive 1-2 runs of the garbage collector
are eventually moved to the
old generation, which is much larger at about
by default. As few objects make it to the old generation
and as it is much bigger, garbage collection in the old
space, although more expensive, is infrequent.
It is only when this bigger old-space gets full and there
are no objects that can be swept to free up memory that
you start encountering memory allocation problems, e.g.,
The short term work-around is to increase the
old-generation by passing the option
(amount is in MB, so 8GB in this example), however the root
cause is probably a bad architecture (or a memory leak).
The real solution is likely to involve replacing some load all the data and then process it pattern with a streaming approach. This applies, of course, to loading results from a database query. Use pagination if the results are to be displayed in a user interface or streaming if you need to process them all in some cron job.