The other way to ask this question is, are Blender's memory limitations solely hardware related? Or, is there a point at which Blender will either crash or fail to use additional memory, even though there is more memory still available on the machine?

Speculation isn't useful, but anecdotal evidence is, i.e. "I have 64GB of RAM and Blender has used all of it." Or "I have 64GB of RAM and Blender crashed trying to render a scene that required 16GB."

Even more useful than that is a software engineer's answer about how Blender actually works (not should work, not if it was coded the way I'd code it; what it actually does).

  • $\begingroup$ I just did a little test, and at 31468MB (~32GB), the system killed it for using too much resources. It didn't crash, it was gracefully shut down by the kernel. $\endgroup$
    – user7952
    Commented Dec 15, 2014 at 16:37
  • 1
    $\begingroup$ Let me just say that if you've got 64gb of RAM, you shouldn't have a problem. $\endgroup$
    – ruckus
    Commented Dec 15, 2014 at 16:43
  • $\begingroup$ I have 24GB RAM and 24GB swap, so I'm quite surprised the kernel let it live that long. $\endgroup$
    – user7952
    Commented Dec 15, 2014 at 16:43

2 Answers 2


What is memory management (from http://www.tutorialspoint.com/):

Memory management is the functionality of an operating system which handles or manages primary memory. Memory management keeps track of each and every memory location either it is allocated to some process or it is free. It checks how much memory is to be allocated to processes. It decides which process will get memory at what time. It tracks whenever some memory gets freed or unallocated and correspondingly it updates the status.

There is no software cap. There can't be - it would have to be coded in for it to be. Blender will use all your RAM up to 16TB (64bit). Its up to the OS to provide the memory for blender.

If you have a page file it starts at around 2 GB or 4 GB and windows expands the page file when needed. However, they might not be as fast as Blender requests more memory. If this happens, Windows does not allow Blender to get more RAM and causes an out of memory exception which crashes Blender.

At that point the page file gets bigger and in second run of Blender its very likely everything will run/render without problems.

If your OS fails to allocate some memory for Blender fast enough, Blender will crash.

  • $\begingroup$ This is (almost) exactly what I was looking for. To be fair, there COULD be a software limit, if it were "coded in," but your explanation clarifies why it's reasonable to assume there isn't such code. +1 for ALSO explaining why Blender would be told it can't have more memory, even though (hypothetically) I clearly have more disk space for dynamically allocated virtual memory. Thanks! $\endgroup$
    – Matt
    Commented Dec 28, 2014 at 2:39

I have personally witnessed Blender utilizing 18GB+ of RAM during Cycles renders, 15GB of RAM while UV unwrapping highly subdivided meshes, and using all 64GB of physical RAM during various simulations. The following show Blender utilizing all system memory:

Blender 2.7x process using 58.4GB during simulation Blender utilizing full system RAM during fluid simulation

It's not unheard of to run into Blender coding errors in memory management which can limit scalability such as the following:


However, as others have mentioned, these limits are not by design.

  • 2
    $\begingroup$ Show me some software memory limitations (the code is opensource), because it does not have any!. Also this bug is not a bug and the operating system shuts down Blender. $\endgroup$ Commented Dec 16, 2014 at 10:38
  • $\begingroup$ @Jerryno I must agree with you. I just tried this, and Blender was indeed shut down by the OS. I monitored all processes running, and Blender received a STOP signal sent by the kernel, and there was no coredump. $\endgroup$
    – user7952
    Commented Dec 16, 2014 at 11:18
  • $\begingroup$ How much RAM did you test with @SixthOfFour on what OS? I've tested again with 2.72b Win64 which crashes at 9.8GB but 2.71 Win64 completes without issue using 11.5GB. This behavior appears to indicate a Blender software limitation rather than OS. $\endgroup$
    – futurehack
    Commented Dec 17, 2014 at 4:57
  • $\begingroup$ I was using Blender Internal in 2.72b on FreeBSD 10.1 with Xorg 7.7 and WindowMaker 0.95.6, 24GB RAM and 24GB swap. The CPU is an i7 960. In this specific test, Blender was closed using just below 10GB and about 98% of available CPU. In another test I did, with a ~13 million vertex solidified sphere with a transparency depth of 16, Blender was closed using ~32GB and about 35% of available CPU during the raytree building phase. It was closed by receiving a signal from the kernel. If it had crashed, there would have been a coredump. $\endgroup$
    – user7952
    Commented Dec 17, 2014 at 6:21
  • $\begingroup$ This may well be related to Blender, and if so it's probably something specific to the UV unwrapping. However, it doesn't suggest a hardcoded RAM limit, as that would most likely have caused an out-of-memory crash, and unless rendering and UV unwrapping have separate memory management, it would most likely have happened at roughly the same RAM usage. $\endgroup$
    – user7952
    Commented Dec 17, 2014 at 7:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .