I can't seem to repro this behavior on windows either. What exact build of 2.79a are you running? (the splash screen should have a hash on it, that would help narrowing this down)

edit: also is this a blender.org build or something from the ubuntu repositories?

Hash is: 8928d99270f (as of 2018-02-21 10:41)

What makes me wonder is that 2.79 works fine, but 2.79a shows this behaviour with exactly the same settings and scene.

i tried with both 2.79a and a recent master build, can't seem to trigger the issue with fishy_cat_cpu.blend maybe it's scene related? also i probably was too late editing my post, but where did you obtain the blender build? from blender.org or did it come from ubuntu's repositories?

LazyDodo, thanks for trying.
IMO it's not scene related, because it does work normally with 2.79.
The build is from blender.org and I am not using Ubuntu but Debian stable. Since the 2.79a release I never had any problems like this one.

It can be scene related also if it works normally in 2.79, since there can be a new bug in 2.79a that is only triggered by specific scene setups. So ideally we want statistics from a scene that we can test ourselves, to figure out where exactly the difference is.

I can see differences between Blender versions, but some randomness and delay in releasing the memory to the operating system is expected. The memory statistics in the system monitor do not tell you the actual memory that is used and available, only an approximation that can be off quite a bit. What is a problem is if re-rendering the same scene increases memory usage each time and eventually fails due to running out of memory, and I have not been able to reproduce that.

What you can try is running Blender like this, and tell us how it affects memory usage. It will make Blender release memory to the operating system quicker and eliminates some of the randomness.

MALLOC_CONF="dirty_decay_ms:0" ./blender

I am able to reproduce the problem with Blender 2.79a official release and this scene:

My system: Kubuntu Linux 18.04 64bits - GTX 960 4GB - i7 3770 - 15.6GB RAM available.

Steps (All the procedure is without closing Blender):

*2.79a
Open High RAM scene.blend scene, Render image. After finished System Monitor reports Blender still uses about 12.6GB.

File > New > Reload Start-UP file. Turn to Cycles. Render image (default cube). After finished System Monitor reports Blender still uses about 11.9GB.

File > Open Recent > High RAM scene.blend. render Image. After finished System Monitor reports Blender still uses about 12.8GB

So apparently memory is never freed, but apparently it is not cumulative either.

*2.79
The behavior is different, while render scene simply it reaches a peak of 13GB, but frees the memory when it ends.

i had to dial down the particle system a tiny bit because of ram issues but this is the memory curve i got on windows with 2.79a with that file

@YAFU (YAFU), does running Blender 2.79a like this cause the reported memory usage to be reduced after rendering?

MALLOC_CONF="dirty_decay_ms:0" ./blender

@Sergey Sharybin (sergey), did the jemalloc version change for 2.79a?

@Ray Molenkamp (LazyDodo). Maybe just Linux issue? My system monitor graphic with Blender 2.79a is basically a permanent horizontal line at approximately 13.5 GB :)
Just in case, using 4.15 linux kernel here.

@Brecht Van Lommel (brecht) Van Lommel. I had forgotten to try it. Running Blender 2.79a with "MALLOC_CONF="dirty_decay_ms:0" ./blender" it works fine, memory is freed.

@Brecht Van Lommel (brecht) also for me: "MALLOC_CONF="dirty_decay_ms:0" blender" works fine.
No cumulation of allocated memory on system monitor/blender monitor. Memory is freed after rendering, loading new scene.
Seems to work fine with that env variable setting.

@Brecht Van Lommel (brecht), jemalloc indeed changed for 2.79a. The reason for that was that previous update introduced rather dramatic slowdown for things like Draw Manager behavior in 2.8. This slowdown was fixed by jemalloc-5.0.1, but seems it introduced some other issues?

It seems the dirty page purging totally changed:
https://github.com/jemalloc/jemalloc/releases/tag/5.0.0
https://github.com/jemalloc/jemalloc/issues/325

Purging dirty pages is slower than before when opening a big .blend and then doing file > new, but it still happens after some time in that case. This can be explained by the default 10s delay:
http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms

However for rendering we allocate memory in different threads, and according to this comment that can be problematic:

(a lot of your arenas only have one thread in them -- if that thread is sleeping or otherwise not interacting with the allocator much, it might never get far enough into the arena code to purge).

And indeed, if we render a simple scene afterwards a few times it wakes up the render threads, and memory goes down a bit each time. Similar behavior happens for Cycles, Blender Internal, baking, etc. The suggested solution seems to be enabling jemalloc background threads:

diff --git a/source/creator/creator.c b/source/creator/creator.c
index a59a45f..15b4169 100644
--- a/source/creator/creator.c
+++ b/source/creator/creator.c
@@ -201,6 +201,10 @@ char **environ = NULL;
 #  endif
 #endif
 
+/* If jemalloc is used, it reads this global variable and enables background
+ * threads to purge dirty pages. Otherwise we release memory too slowly. */
+const char *malloc_conf = "background_thread:true";
+
 /**
  * Blender's main function responsibilities are:
  * - setup subsystems.

With that option it seems to purge all the dirty pages within about 10s after rendering as expected. It's not entirely clear to me if this would solve all potential problems though. Suppose we allocate and free a bunch of memory in one thread, and then do the same in another thread soon afterwards. Can it now run out of memory if the sum of what the two threads allocated is too high? The background threads are not going to be able to purge the pages quick enough, so will jemalloc do it in some other way to avoid running out of memory?

@Brecht Van Lommel (brecht), i propose the following:

• We make 2.79b with previous version of jemalloc, just so we are safe and everything.
• We use your solution for master branch and see how that behaves. We shouldn't be locking to an older jemalloc versions, lots of distros are moving to a newer versions now.

I'm also quite sure jemalloc is used in other software, including Firefox with all this separate threads for JIT compilation and such. Can totally check how it's used there or ask developers.

Sounds like a good plan.

Firefox did not upgrade to jemalloc 4 or 5, they're using a customized earlier version of jemalloc.
https://bugzilla.mozilla.org/show_bug.cgi?id=1363992

@Brecht Van Lommel (brecht), 2.79b builds are done. If you can verify they're fine it'll be great! The buildbot is back to jemalloc 5.0.1, so this issue we need to address in one way or another.

Just verified with Campbell. The issue is solved in 2.79b by using older jemalloc.

Buildbot is on newer jemalloc, so let's see what we can do there.

@Brecht Van Lommel (brecht), Using MALLOC_CONF="dirty_decay_ms:0" solves the issue. Tried your patch, but this gives me:

<jemalloc>: Error in dlsym(RTLD_NEXT, "pthread_create")
Aborted

on the very startup.

There's a bug report about that error here, I guess you are using 5.0.1 with the fix already?
https://github.com/jemalloc/jemalloc/issues/907

It seems there are multiple issues depending on static / shared libraries and linking order, and not all of them may be solved. It worked for me with a static jemalloc 5.0.1 and no changes to the build system, not sure how your setup is different.

I think dirty_decay_ms:0 is not intended for production use and performance is expected to be poor, not sure how much it matters in practice but probably it's not a good idea to use it.

@Brecht Van Lommel (brecht), i'm dynamically linking against libjemalloc v5.0.1 here. Did you talk to those folks about how to make newer jemalloc usable for Blender? :)

I can confirm this or a similar issue with 2.80 (build "2.80-f8908f0d434-linux-glibc219-x86_64"). When I try to render about 300 frames of the default cube animation above, my system memory usage increases by about 7 GiB while Blender itself only reports about 100 MB of memory being used.
The output format in this file is set to "Ffmpeg video"; my ffmpeg version is 4.0.

I changed the render samples to 1 and render size to 50% to speed up things.
I started rendering. System memory consumption raises to >16GB after short time with blender displays memory usage around 70MB.
I can confirm Lukas' observation. I used blender-2.80-fbd614f1faf-linux-glibc219-x86_64 on a Debian stable system with a GTX1060.
Seems as if the jmalloc problem is here again??

Seems to be related to what I reported here https://developer.blender.org/T56825 I'll try the MALLOC option

I confirm that MALLOC_CONF changed the behavior on my computer with 20G RAM and 1060 ti (3g) NVidia card on Fedora 28. Memory seems to be cleaned and I do not have computer freeze after several renders.

I still have the problem in 2.79 and 2.8 from Buildbot builds. Compiling Blender by myself the problem does not happen. I suppose that is due to the version of jemalloc installed in my system (3.6.0)