BookmarkSubscribeRSS Feed
ghastly_kitten
Fluorite | Level 6

Hello everyone!

Does anybody face a problem with SAS EG eating up almost all available RAM?

I'm not sure that it is a bug, so I haven't posted something about it to support.

The situation I have is usually as follows:

I'm starting EG, after a few hours of coding I'm discovering the slow motion on my machine, then I'm starting task manager (Win Server 2003 x64) and observing that EG ate 1.5 Gb of RAM.

As I have a slightest idea about the nature of this memory consumption, I have no opportunity to limit or prevent it.

For example, will it be helpful if I unembed all code in the project?

Any experience will be helpfull!

Best regards

13 REPLIES 13
TomKari
Onyx | Level 15

One possibility is that some results can be very large, particularly in html and pdf formats. You could change your settings to open your results outside of EG, and see if this helps.

Tom

ChrisHemedinger
Community Manager

If you see the memory climbing when working with the programming editor, check the guidance in this paper:

http://support.sas.com/documentation/onlinedoc/guide/blog/WPF_SASEG43.pdf

Chris

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
ghastly_kitten
Fluorite | Level 6

Well, I failed to change the WPF tier to something from 0x0, but alas.

However, I still think that that problem is more about EG resource management and garbage cleaning, and not about rendering.

Any other ideas would be usefull.

Thanks anyway!

ghastly_kitten
Fluorite | Level 6

TomKari

Well this might've been a problem in case there were pdf and html output. However, there's none.

Chris@SAS

Well the only hint I found was about WPF (which uses software rendering on my server). I'm accessing EG through RDP client, so I'm not sure (beeing not a specialist in WPF) how this affects the ability of hardware rendering. But I'll try to figure it out and at least update video adapter driver.

SASKiwi
PROC Star

One EG option that I suspect impacts memory usage is whether you have the project log switched on or not. Since I find it highly useful I leave it switched on but memory tends to climb over time.

While I use EG primarily to code SAS programs it is worth remembering that every time you run a program this is added to the process flow. If your programs create lots of SAS datasets these get added to your process flow also. Cleaning out your process flow from time to time will reduce your memory usage, but only do this if you program in EG by writing code and only use program files for project development.

I use EG 5.1 64-bit and find that over a day EG can easily consume up to 1 GB of memory.

ChrisHemedinger
Community Manager

Because SAS Enterprise Guide is a .NET application, there are nuances to how memory is managed. You can't really tell too much about how efficient the application is simply by looking at the Working Set value.

The .NET runtime is generous with initial memory allocations, if there are available resources. Over time, you might see memory use climb if you look at the Working Set number in Task Manager. But when resources get tighter on the system, you should see that number go back down. 

For example, suppose that you start EG and open a large report. When the report is opened and rendered, you'll probably see memory use increase. When you close the report view, the application will free the memory, but you might not see the working set number decrease right away. That doesn't indicate a problem. It's only a problem if, over time as you use the application, memory use climbs and climbs and never goes down, even if your activity remains level.

One trick that sometimes works to show this: minimize the application and then restore it. You might see the working set go down. That's kind of like "jiggling the handle", but it doesn't really indicate a leak. It's just triggering Windows and the .NET runtime to clean up, which would have happened sooner or later.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
ghastly_kitten
Fluorite | Level 6

The problem is the memory climbs and climbs in average.

I usually restart EG after it consume 1.5-1.7 Gb, because it's nearly impossible to work with it: everything drastically slows down.

But I have feeling that if I don't quit it, EG will eat up to 2 Gb and further...

ghastly_kitten
Fluorite | Level 6

SASKiwi wrote:

One EG option that I suspect impacts memory usage is whether you have the project log switched on or not. Since I find it highly useful I leave it switched on but memory tends to climb over time.

While I use EG primarily to code SAS programs it is worth remembering that every time you run a program this is added to the process flow. If your programs create lots of SAS datasets these get added to your process flow also. Cleaning out your process flow from time to time will reduce your memory usage, but only do this if you program in EG by writing code and only use program files for project development.

I use EG 5.1 64-bit and find that over a day EG can easily consume up to 1 GB of memory.

Well, I do use EG ONLY to code SAS programs (never use built-in tasks) and my process flows usually consist of program files, datasets and results(from graphics or report functions). But what do you mean of 'cleaning out your process flow from time to time' ?

Let's assume I have a several step tree process: each step generate 2 datasets which then used by seperate program file to produce next two datasets and etc.

Given this datasets are all necessary to be saved in library, how do I clean the process flow?

p.s. Your comment on this problem is very close to what I have.

arnab61
Calcite | Level 5

Probably you can try this for deleting the temprary workspace on a regular interval,

proc datasets lib=work kill nolist;

run;

Lets see if it fress some of your workspace memmory.

ghastly_kitten
Fluorite | Level 6

Is it about RAM?

Okay, I'll try next time.

By the way, do you know any method to clear unnecessary TMP files like old results/plots? Which are not in WORK directory.

I mean some results generated by EG in case of running some graphical procedures (like GMAP or SGPLOT).

SASKiwi
PROC Star

To clean out the process flow I just go to the Project Tree - Process Flow - Programs and delete those I am no longer working on. You will be prompted to save program files if they are not already saved. I find that the program tasks taking up the most memory are those producing lots of datasets as each of these becomes a process flow object as well. Deleting the program removes all process objects associated with it as well including dataset definitions, but obviously not the actual datasets on disk.

ghastly_kitten
Fluorite | Level 6

MMMmm... I see. Since I use EG to hardcode report production and calculation - there is no garbage in process flows.

But thanks, anyway.

Wenduhlin
Calcite | Level 5
Yes. i was planning a asking a similiar question. I think it's because of the size of my dataset(s); which is why i remove datasets that i no longer need.
I found info about managing memory at http://support.sas.com/documentation but I do not know where/how i can change modify options
i do not have permission to modify my config file.

Managing Memory
Specify a Value for MEMLEAVE= When You Invoke SAS
Use SYSLEAVE= and PROCLEAVE= to Handle Out-of-Memory Conditions

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 13 replies
  • 6446 views
  • 6 likes
  • 6 in conversation