"Failed to free sufficient memory to reach the process usage limit"
This warning is appearing my log files. What do I need to do about it? What is the potential impact if nothing is done?
As far as I can tell there is nothing wrong with the output files the script is creating.
It's a warning that FME is running low on available memory. I think the best solution is to switch to 64-bit FME, if you can. That way you'll have less limitations on how much FME can consume, which usually fixes the issue.
Potential impact is that FME can start swapping process memory to disk during translation, which will have a very negative effect on workspace performance.
I would also point to the following part of the documentation: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/Workbench/memory_resources_adjusting.htm
It's a warning that FME is running low on available memory. I think the best solution is to switch to 64-bit FME, if you can. That way you'll have less limitations on how much FME can consume, which usually fixes the issue.
Potential impact is that FME can start swapping process memory to disk during translation, which will have a very negative effect on workspace performance.
I would also point to the following part of the documentation: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/Workbench/memory_resources_adjusting.htm
umm, how do I check the bit-ness? I have "FME(R) 2019.0.0.1 (20190415 - Build 19246 - WIN64)". Does the 64 in string refer to Windows or FME?
umm, how do I check the bit-ness? I have "FME(R) 2019.0.0.1 (20190415 - Build 19246 - WIN64)". Does the 64 in string refer to Windows or FME?
Hi @maphew That string refers to FME. Since you're already using 64-bit FME, please try FME 2019.2 or the latest 2020 beta. If you still have memory problems then send details of the problem to https://www.safe.com/support/report-a-problem/
As @david_r and @danatsafe have said it memory related. If you've got a lot of browser tabs open or several Data Inspector windows open while running a job you might get this a lot. Just kill off a few things, it will also speed up the process by letting FME have a few more resources.
As @david_r and @danatsafe have said it memory related. If you've got a lot of browser tabs open or several Data Inspector windows open while running a job you might get this a lot. Just kill off a few things, it will also speed up the process by letting FME have a few more resources.
I had 9 GB free ram (of 32GB) and lots of swap space, 150GB. However rebooting cleared the warning. It would be nice if the message included what FME asked for and couldn't get.
The post-reboot FME log finished with "END - ProcessID: 23252, peak process memory usage: 79900 kB, current process memory usage: 79900 kB". 79 MB is orders of magnitude under what Windows reported as free before reboot.
I had 9 GB free ram (of 32GB) and lots of swap space, 150GB. However rebooting cleared the warning. It would be nice if the message included what FME asked for and couldn't get.
The post-reboot FME log finished with "END - ProcessID: 23252, peak process memory usage: 79900 kB, current process memory usage: 79900 kB". 79 MB is orders of magnitude under what Windows reported as free before reboot.
Just remembered I did make one change pre-reboot: I defined FME_TEMP system environment var, before that it was not set at all. There's 65GB free on Windows TEMP volume though, should have been enough.
I had 9 GB free ram (of 32GB) and lots of swap space, 150GB. However rebooting cleared the warning. It would be nice if the message included what FME asked for and couldn't get.
The post-reboot FME log finished with "END - ProcessID: 23252, peak process memory usage: 79900 kB, current process memory usage: 79900 kB". 79 MB is orders of magnitude under what Windows reported as free before reboot.
The message, as far as I know is always memory related. When you start the process FME checks the current state which appears to be present for the whole process.
You can check in the log file near the top to see the configuration.
2019-02-25 12:29:18| 0.2| 0.0|INFORM|FME Configuration: Start freeing memory when process usage exceeds 46.32 GB of virtual memory
2019-02-25 12:29:18| 0.2| 0.0|INFORM|FME Configuration: Stop freeing memory when process usage is below 34.74 GB of virtual memory
The lines here represent the max points at which FME will try to stach to the FME Temp.
The first number should be about 3 times the amount of physical ram you have (so should be around 96 GB for you) - when the process reaches this value it will start stashing to disk. In reality this number will be much lower due to other processes running and is constantly monitored (as I understand).
The message you are seeing in your log, I think, comes when FME tries to stash data to the disk until the process reaches the second number. The key word it Tries, if the process requires the data to be in memory then it will keep it in memory and report the log that you see.
One problem that I have noticed is that if you start the process in a state which you have used a lot of memory already then these numbers can be very low, as low as 30 MB when the process starts (I think it's a bug?). Check this part of the log file if you still have it to see what the numbers say. If they are low then FME will continuously be trying to save data to the disk even when it doesn't need to and you will get this message through the whole process.
If you run out of free space then it will just crash.
The message, as far as I know is always memory related. When you start the process FME checks the current state which appears to be present for the whole process.
You can check in the log file near the top to see the configuration.
2019-02-25 12:29:18| 0.2| 0.0|INFORM|FME Configuration: Start freeing memory when process usage exceeds 46.32 GB of virtual memory
2019-02-25 12:29:18| 0.2| 0.0|INFORM|FME Configuration: Stop freeing memory when process usage is below 34.74 GB of virtual memory
The lines here represent the max points at which FME will try to stach to the FME Temp.
The first number should be about 3 times the amount of physical ram you have (so should be around 96 GB for you) - when the process reaches this value it will start stashing to disk. In reality this number will be much lower due to other processes running and is constantly monitored (as I understand).
The message you are seeing in your log, I think, comes when FME tries to stash data to the disk until the process reaches the second number. The key word it Tries, if the process requires the data to be in memory then it will keep it in memory and report the log that you see.
One problem that I have noticed is that if you start the process in a state which you have used a lot of memory already then these numbers can be very low, as low as 30 MB when the process starts (I think it's a bug?). Check this part of the log file if you still have it to see what the numbers say. If they are low then FME will continuously be trying to save data to the disk even when it doesn't need to and you will get this message through the whole process.
If you run out of free space then it will just crash.
I have experienced the same. If there is some other software using lets say 90% of memory when starting the workspace then it have only 10% left for that FME instance. If the other process finishes then the running FME Workspace does not use more than 10% - even though there is more available RAM. FME seems to calculate these values at startup, and not alter them during a long run.
I have experienced the same. If there is some other software using lets say 90% of memory when starting the workspace then it have only 10% left for that FME instance. If the other process finishes then the running FME Workspace does not use more than 10% - even though there is more available RAM. FME seems to calculate these values at startup, and not alter them during a long run.
@ryanproulx - just pinging you on this one. Perhaps you're aware perhaps not. Also maybe you can check that my explanation is in the realm of right.
It's a warning that FME is running low on available memory. I think the best solution is to switch to 64-bit FME, if you can. That way you'll have less limitations on how much FME can consume, which usually fixes the issue.
Potential impact is that FME can start swapping process memory to disk during translation, which will have a very negative effect on workspace performance.
I would also point to the following part of the documentation: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/Workbench/memory_resources_adjusting.htm
Something doesn't seem to be right with this error. I'm getting the same:
Failed to free sufficient memory to reach the process usage limit. To improve stability and performance please increase the memory available to FME. Available memory can be increased by adding physical RAM, increasing swap space, or closing other applications
WorkspaceRunner_10: Failed to run workspace
I am working with FME 2019.2 64 bit. I have 32 GB of RAM, half of which does not even get used during the workspace run. FME builds up a large temp file called 'FME_OBJC_SpatialFilterFactory_groupByStash_1583325603968_18612' of 360 GB. Especially for this process I have added a 1 TB HDD on which my FME_TEMP is located.
So, there is plenty of physical RAM and plenty of swap space and still, the process fails.
What's wrong here?
I think there is still potential to improve performance by redesigning the process, especially by changing the blocking SpatialFilter to it's advanced settings. However, I still don't understand where the error comes from in my case.
Something doesn't seem to be right with this error. I'm getting the same:
Failed to free sufficient memory to reach the process usage limit. To improve stability and performance please increase the memory available to FME. Available memory can be increased by adding physical RAM, increasing swap space, or closing other applications
WorkspaceRunner_10: Failed to run workspace
I am working with FME 2019.2 64 bit. I have 32 GB of RAM, half of which does not even get used during the workspace run. FME builds up a large temp file called 'FME_OBJC_SpatialFilterFactory_groupByStash_1583325603968_18612' of 360 GB. Especially for this process I have added a 1 TB HDD on which my FME_TEMP is located.
So, there is plenty of physical RAM and plenty of swap space and still, the process fails.
What's wrong here?
I think there is still potential to improve performance by redesigning the process, especially by changing the blocking SpatialFilter to it's advanced settings. However, I still don't understand where the error comes from in my case.
Wowsers 360GB!! I'm impressed! I would contact support on this issue - They may not be able to recreate it, however, they may have a little more insight as to what might be happening of why a workspace might fail in this scenario. Perhaps if we ping @mark2atsafe he can try and get this thread looked at by a dev who might be able to shed some light for us.
Hi
I am getting the same message, on meek and mild work bench, only reading xml file with 3500 records. A few times the work bench crashed
13Gb Ram free - FME_TEMP is on SSD, 8677, runing 64-bit FME message appears in 2019.2.3 and 2020 version
2020-03-22 12:23:47| 24.3| 21.4|WARN |Failed to free sufficient memory to reach the process usage limit. To improve stability and performance please increase the memory available to FME. Available memory can be increased by adding physical RAM, increasing swap space, or closing other applications
2
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 677.47 GB of disk space available in the FME temporary folder (C:\\Temp)
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 13.88 GB of physical memory available
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 16.81 GB of virtual memory available
2020-03-22 12:23:10| 0.8| 0.0|INFORM|Operating System: Microsoft Windows 10 64-bit (Build 18362)
Hi
I am getting the same message, on meek and mild work bench, only reading xml file with 3500 records. A few times the work bench crashed
13Gb Ram free - FME_TEMP is on SSD, 8677, runing 64-bit FME message appears in 2019.2.3 and 2020 version
2020-03-22 12:23:47| 24.3| 21.4|WARN |Failed to free sufficient memory to reach the process usage limit. To improve stability and performance please increase the memory available to FME. Available memory can be increased by adding physical RAM, increasing swap space, or closing other applications
2
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 677.47 GB of disk space available in the FME temporary folder (C:\\Temp)
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 13.88 GB of physical memory available
2020-03-22 12:23:10| 0.8| 0.0|INFORM|System Status: 16.81 GB of virtual memory available
2020-03-22 12:23:10| 0.8| 0.0|INFORM|Operating System: Microsoft Windows 10 64-bit (Build 18362)
Hi @rudy_v sorry to hear that you are running into issues with FME. May I suggest logging a case with our Support Team at the following link https://www.safe.com/support/report-a-problem/ .
Hi @rudy_v sorry to hear that you are running into issues with FME. May I suggest logging a case with our Support Team at the following link https://www.safe.com/support/report-a-problem/ .
@daraghatsafe - any feedback/update on this issue? running into this on 2020.1.1.1 here
Hi @rudy_v sorry to hear that you are running into issues with FME. May I suggest logging a case with our Support Team at the following link https://www.safe.com/support/report-a-problem/ .
Hi @1spatialmary sorry to hear that you are having these problems also. I haven't seen any new feedback on this issue, I may suggest trying FME 2020.1.2.1 to see if the problem is the same. If it is the same I would suggest creating a case. https://www.safe.com/support/report-a-problem/
Hi, Not sure what the outcome is of this issue, might it have something to do with Virtualization or the Windows OS used? I used to run FME Desktop 2017 on Windows 7 and never had this issue. Now we moved to Windows 10 and I usually see this message. Cleaning up %TEMP% folder and/or Purging FME Temporary files does not solve the problem. Reboot does.