Hi FME'ers,

Today's Question-of-the-Week queries a log message about memory usage. The concern is what the message means and what can be done about it. 

Q) This warning is appearing my log files:

Failed to free sufficient memory to reach the process usage limit

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.

Asked here by @maphew

A) In short, this message tells you that FME is becoming short of memory. If you don't do anything about it then - as long as the process finishes - you are correct that the output will be fine. But let's dive a bit deeper into why this message occurs...

So, FME has built into it, tools for what is called Memory Management. In other words, we don't just start transforming data without considering the state of the computer. We try to calculate how many resources we can use for optimum FME performance, without being so greedy as to cause system problems.

This is indicated by these lines in our log file:

System Status: 18.00 GB of virtual memory available
Operating System: Mac OS X Version 10.14.4 (Build 18E226)
FME Configuration: Process limit is 16.00 GB of physical memory
FME Configuration: Start freeing memory when process usage exceeds 16.83 GB of virtual memory
FME Configuration: Stop freeing memory when process usage is below 12.62 GB of virtual memory

Basically (in this example) we have 18gb of memory available to FME: the remainder of the 16gb of physical memory, and a certain amount of disk space called virtual memory.

FME will read into that memory, features that are being processed. We'll keep as many features as possible in memory, because it's the quickest way to access them for processing. 

However, once we've used up 16.83gb of memory, to avoid making the system unstable, we'll start releasing features that aren't immediately required. Then we can add features that are needed, without causing memory shortages.

Once our usage goes back below 12.62gb, then we'll stop actively releasing features, because we feel we're no longer in danger of destabilizing the system.

So far, so good. But where does the error message come in?

So what the error above means is this: FME has gone past its maximum usage (here 16.83gb) and tried to release features that it can temporarily do without. However, having released as many features from memory as possible, we're still over the usage limit.

In other words, we've run short of memory and there's not much more we can do about it.

So what happens? Well, we carry on processing. We hope that nothing bad will happen, but the system may become unstable. Hence the warning message.

Provided processing finishes without further problem, the results will be fine. We breached our intended memory limit but nothing bad happened. Phew!

But how and why did we get to that point? 

Sometimes the memory limit is exceeded because FME is handling a huge amount of data and really needs to hold a lot of it in memory at once. 

But another reason is the other applications running on the computer.

If you let an FME workspace run and then simultaneously start up a new, memory-intensive application, then it may start using resources that FME initially relied upon. Similarly, if memory-intensive applications are already running when you start an FME translation, FME might be more cautious about what its limits are.

The solution is to not run so many other applications that FME is constrained to use less memory than it would like. In fact, we just changed the message in 2019.2 to include the following:

So to summarize all of that:

• FME actively manages its performance based on the resources available to it.
• Other applications can eat into those resources, leading to messages such as this one.
• By closing other applications (or otherwise making more memory available) then the risk is reduced.

Overall it's a rare message, but one to look out for.

Here are some other questions I noticed or was asked this week:

• Does anyone know a way of calculating working days between dates? 
  • This is the sort of question we love on this site! A mildly tricky problem that's easy to grasp, doesn't have an existing solution, and is potentially useful to many of us. Here there are several solutions. @redgeographics suggested using an API, and both @david_r and @ebygomm proposed Python-based solutions. Then myself and @gazza suggested methods using workspace transformers.
  • They're all fine answers in their own way. An API is necessary if you want to include public holidays, because that's not something we'd want to maintain in FME. Python is probably going to run faster and you can re-use Python code from elsewhere. Transformers are more user-friendly to non-programmers. If you're interested, browse to the question and check out all the answers.
  • I do acknowledge, by the way, that my solution is packaged up more nicely as a hub transformer only because I have more time at my disposal. I salute all users who use their own time to answer questions and develop solutions on this site. Without you this community would not exist. You have my total respect.

• Can you share my FME-related job posting with the community? 
  • Absolutely, although obviously I'm just sharing them not making any recommendations. In fact I'm seeing quite a few job opportunities this week, including some at Safe. Here's what I have:
    • We currently have multiple openings with Safe, based at our offices near Vancouver. They include tech support (the team I work with), product testing/QA, product management, marketing, sales, and many more! If you want any more info about a particular role, then feel free to ask.
    • Here's one for a GIS technician that includes FME'ing. The company is also based in Vancouver, but the role allows for remote working.
    • Just as I was writing this, one of our partners tweeted about job vacancies in the UK, including a couple in their special FME division. Great timing!

• How can I speed up the NeighborFinder or find the neighbors quicker mathematically?
  • Another type of question that I like, this from @gpt_executer. There are some great suggestions. I agree with the answer that our transformers are probably designed to be as efficient as possible. However, the fact that the features are known in advance to be points, and have a grid layout, may make a better solution feasible. I'm thinking maybe even a SQL solution in the InlineQuerier?

• Incorrect results from StatisticsCalculator's cumulative output
  • Not that I want to have to highlight this, but there does appear to be a problem with the StatisticCalculator's cumulative output port in 2019.1 or newer. I believe it's fixed in 2020 but a backport to 2019 doesn't seem possible. Luckily - as clickbait articles would say - this one weird trick will solve your StatisticCalculator problems, so check out the answers for more info!

@david_r:- Have you tried disabling certificate validation in the HTTPCaller? How to do this can you give more bit more information?

Is it in HTTP client options?

Exactly, under the http client options in the HTTPCaller:

Yes i did the same, It is working now. Thank you very much David...

@david:- Can i get some more information about this context, like it was running fine until yesterday night, Why all of sudden today jobs were failed? Till yesterday Verify SSL Certificates: Enabled(Yes). what could be the reason for this issue?

SSL certificates are usually automatically rotated on a regular basis, e.g. every 3 to 6 months, it could be that there has been a subtle change in either the certificate or the proxy software (if you're behind one) since yesterday. Perhaps your IT department can help you further.

Okay, Thank you again for the information....