Java Program Taking Up 40GB+ of RAM
1 Attachment(s)
I am using filebot on my 14.2 install with jdk (v8) from SBo to move some files around on my system and it is currently taking 55.0G of VIRT and 45.1G of RES according to htop. This happens regularly with this program (and I remember it happening with another java program, but I can't remember what it was). When it gets this big, I usually just close it and reopen it and it will reset the memory usage, but it always will continue to balloon up until it requires closing and reopening.
pmap -x shows the Kbytes as 54G (57693260K) and the RSS and Dirty at 44G (47217524K and 47208756K, respectively). The java program has spawned 83 threads. I have 64GB of RAM installed, and it seems that filebot will use up to a percentage of that, because I don't recall it ever going over my installed RAM amount, even when my system was running 32GB of RAM. I've attached the output of the pmap -x command, in case it is helpful for anyone. I know very little about java, but researching online lead me to add -Xmx512m to the launch command to try and curtail this memory usage, yet it had no effect (at least not that I noticed). Any suggestions on what I can do to change this behavior? I'll keep filebot open for some time in case anyone wants me to run commands against it. |
Sounds like a memory leak. Maybe I'm blind, but I can't find Java version requirements anywhere. Maybe there is a Java version mismatch. Linked slackbuild is quite old (22.3.2017). Have you tried newer version? According to their forum latest is 4.9.3 from 16.3. Anyway, best bet I would say is to contact developer through the mentioned forum.
|
Quote:
It seems that the java on my system has no limit for the amount of memory it can use. It ends up quite frustrating when a single program takes up 10s of GBs of RAM. |
Quote:
For filebot I see you have a lot of threads. May be you can limit them with -Xss option ? |
Is it a pure java application or does it have other components (e.g. native libraries)? It would be surprising if the Java VM violated the -Xmx option by that much.
There is a (cryptic) way of monitoring the memory consumption of the VM: https://docs.oracle.com/javase/8/doc...ldescr007.html Maybe it helps... |
Quote:
Code:
The stack size specified is too small, Specify at least 228k I also started up Sweet Home 3D and in just placing some objects on a blank plan, Virtual memory shot up to 10.4GB. As another check, I started filebot using jdk11 instead of jdk8 and I'm seeing very similar memory usage. In moving 100 files, it got up to 21.2G VIRT and 14.8G RES per htop. So the memory usage doesn't seemed to be tied to the jdk version. |
Take a look at this:
Restrict size of buffer cache in Linux and start working around the idea of how the Linux kernel manages cache memory. If you copy really big files with 'cp' or even use 'diff' to compare big files, then you'll see how the RAM is consumed really fast and what once was in RAM is now moved to swap. |
Quote:
May be your Java application is allocating big buffers for nothing. Also having a lot of threads is probably not very efficient here in term of allocated virtual memory. |
Check if there is a memory leak in the program with JConsole?
https://www.cleantutorials.com/jcons...h-example-code |
This is my ps aux output for the process so the numbers can be seen:
Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND Quote:
Quote:
Code:
jbhansen@craven-moorhead:~$ jcmd 10492 VM.native_memory summary Quote:
Quote:
I actually logged the VIRT (VSZ) amount and RES utilization (%) during my last moving operation (moving 100 files) and made a graph (thanks to this answer on StackOverflow). You can see it stays pretty level until the copy operations start. Quote:
I took a few screenshots, in case you're any better at reading the output. Overview Tab Memory Tab - Interesting to note that after the file operations stopped, the memory usage dropped, but has been slowly rising since (still only 152MB). If I run garbage collection, the memory usage shown goes down to >50MB, but the amount show in htop doesn't change. VM Summary Tab - This is what shows the large "Committed virtual memory" amount of 22.4GB. Thanks for the suggestions everyone! |
Hello,
I can be wrong but I guess that filebot uses java nio API caches which can lead to native (off-heap) memory leak. To workaround this, you can bound the size of buffers cached in the per-thread buffer caches with property jdk.nio.maxCachedBufferSize. So, try to add -Djdk.nio.maxCachedBufferSize=262144 to the java command line. Hope this helps. -- SeB |
Quote:
Let's hope phenixia2003 found the solution... |
Quote:
https://dzone.com/articles/troublesh...-off-heap-memo It is not a memory leak. The buffers are kept for reuse. But it can be very memory consuming. The parameter in the quoted post can manage the usage of those buffers. In allocators there is always the problem whether it should keep buffers for reuse later or release memory to the system when we don't need it anymore. In the latest kernels the mmap interface add a MADV_FREE flag to release to the system only when there is some pressure of memory. Else if the memory has not been given back, it can be reused directly by the application which release it. Some memory allocator like jemalloc use that new keyword. |
The question is who's fault is this? The actual java program or the java VM? I remember how java is touted for its "memory clean up" or whatever. Sorry that I don't have anything actually useful to contribute, it is the morning - and when it comes to java, I like to shit on it every chance I get; because I just never liked java to begin with.
"B-b-b-ut muh garbage collecsthun." |
Quote:
For file copying adding big buffers as usually done is not very smart as the file are already page copied in memory. So a loop with a small buffer should be better. I think there is some bad habits to use big buffers for copying datas. Streaming and system paging would be better. |
Quote:
I also noticed that jconsole (which I left up overnight while attached to the process) has climbed to 21.8G VIRT (only 360M RES). So, it seems that jconsole invalidates that the VIRT memory usage is tied to file operations as it wasn't doing anything (but maybe the RES memory usage is tied to it). Any other suggestions? |
Hello,
Quote:
-- SeB |
Quote:
1st Filebot - 16.7G VIRT | 10.2G RES 2nd Filebot - 17.8G VIRT | 11.4G RES 3rd Filebot - 22.5G VIRT | 16.1G RES This leaves me with about 4.8GB of available RAM left with my swap maxed out (I have 16GB more swap that can be enabled if needed for testing). Code:
jbhansen@craven-moorhead:~/slackbuilds$ free -h |
Hello,
Quote:
-- SeB |
Quote:
Quote:
Quote:
|
Quote:
|
Hello,
Quote:
Quote:
SeB |
Quote:
|
I would say try a newer openjdk as 8 is ancient and a lot of things wrt to native memory have been improved significantly. But I couldn't get it to work to verify - it just crashes whenever I try to do anything interesting. I tried openjdk 8, 15, and 16 and they all segfaulted I think it's related to libmediainfo.
Maybe you can try ulimit to force a maximum? (-v 20000000 seems about the minimum for virtual memory) Or (yuck) a virtual machine with a fixed memory size and no swap. Looking at the last available public source[1] it looks like it's using java.nio.Files to do file copies/moves, these [2] appear to be mostly native calls and wouldn't use nio ByteBuffer as mentioned above. Also free memory is wasted memory so if it's just the number you're worried about and not system performance it's not very important. On the other hand this just seems like a bug somewhere but there's not much you can do with unsupported software. [1] https://sourceforge.net/p/filebot/code/3968/tree/trunk/ [2] https://github.com/frohoff/jdk8u-jdk...xCopyFile.java |
I was going to look at this, but the idiot behind this application was still using ant to build stuff in 2019 (date of the his last free version). (Not to mention that he's now decided that he needs to be paid for his work; good luck with that.)
His paid version has 4 shared libraries packaged with it; you could certainly have memory leaks from them. The last free version that I found is at https://github.com/deleted-repo/filebot Since he provided no documentation on how to build this, his You may build FileBot for private use on unsupported platforms. is a bit of horse dung. However, he could have deleted the entire repository when he decided to go private; he didn't, so there's that positive bit (and it really is a positive bit). So, if you really like the early version of the app and you enjoy spelunking how to operate a rather obsolete build system, have a go at it. I have better things to do with my time to figure out how some random ant project can be built. (I've written one build system myself and have used ant in the past. I've been doing Java development for 20 years now and would not think of using either the build system that I had written or ant for anything since 2013 or so) I believe that the OP should either:
|
All times are GMT -5. The time now is 08:56 AM. |