SAS Temp Files and Windows Storage Performance

[MargaretC]

The directory/folder associated with SAS WORK is used by all SAS users.  When a SAS session starts, a unique directory is created for the SAS session in the main SAS WORK directory.  Only the user of the SAS session can write to this directory.  And when the SAS session is terminated, this directory is deleted.  

Have you taken any SAS Administration classes?  If not, please look into them as they will greatly help you out.

[JuanS_OCS]

No, in the SASHome folder with the binaries.

Maybe try something like
D:\TempFiles\%USERNAME%

[Kurt_Bremser]

What is the rationale for having user profiles on a network share when you already use virtual desktops on a centralized server? User profiles on a share make sense if you have physical desktops, and users frequently switching between those.

A virtual desktop server for running up to 70 desktops with Enterprise Guide in all of them should be really fat; EG is a 64-bit, .NET based application, and it can (and will) consume lots of memory, particularly when large outputs from the SAS process need to be received and rendered. On top of that, it is possible to run multiple EG instances on one desktop, so that multiplies the requirements.

The SAS compute server itself is a different thing; workspace server sessions can be configured to run with limited memory, depending on the requirements of your users. I maintained a SAS server for a similar number of users with just 128 G of RAM.

[MargaretC]

If by "SAS temp" file you are referring to the file system used for SAS WORK, absolutely.  This file system gets the most IO pressure.

By default, an installation of SAS points SAS WORK file system to a known temp directory so that SAS will work.  The first thing we recommend is to move the location of SAS WORK to the most robust file system you have. 

The same recommendation for a robust IO system is true for EGTEMP.

Please let me know if you need more information.  

[SASExpo]

So these gazillions of TEMP files written to the Windows user profile folders, what is the best way to deal with them?

All users are set for general folder redirection to a share \\userprofiles 

I guess all of this is moot if the general way SAS is used is with local installations and not on a shared terminal server sharing the app to a ton of users.

Our users are not Intranet users with a laptop on the LAN accessing the app.

They are remote users, they VPN in, then RDP to the server with the shared SAS Client app.

If we set the config variable shared in an earlier post, would that redirect SAS temp files?

[MargaretC]

Please reach out to your SAS account team to setup a call with SAS about how to configure your hardware to run properly with SAS.   This is not a conversation that should be done without more details that should only be collected via a conference call. 

[JuanS_OCS]

The main problem here is where the user profiles are, this shared location. They don’t need to be there. Just local is enough and let the Roaming profiles to roam by Active Directory. This change should be fairly easy, but will require to regenerate those profiles.

To answer to your question, the Terminal Sever is not an issue on itself. However for that many users it’s better to use Citrix, or other virtualization systems. Or, if you have a cloud provider, for example Azure, you have availability of Windows Virtual Desktops. Or if you have a big server like this one, I’d rather propose VDIs.

[Sajid01]

Hello @SASExpo
On rereading your posts, I see one important point you have mentioned and something   that should have been taken a note off earlier.
"Our users open a RDP session to a Windows terminal server that hosts the SAS client software, their user profiles for Windows are mapped to a share via group policy."

This makes it clear why a large number of temp files are created at one location, why they accumulate over time and why profiles are stored on a shared server.
My understanding is that Windows OS retains these .tmp  files for   the default duration.

The first option would be to make configuration changes to delete files older than "a set duration" if that is feasible (Not a windows expert). Alternatively write a PowerShell script to take care of this.
I have used the term "a set duration" because in my experience SAS EG users keep their EG projects open for days together, and it is not an easy task to get this workflow changed.  Deleting the tmp file for the session in use could create issues for the user.
Therefore this "set duration " has to be agreed upon by all stake holders. The smaller the better.

If this approach is not workable for any reason, then the other feasible option would be to move the EG client to the user's local machine.