BookmarkSubscribeRSS Feed
webbm
Fluorite | Level 6

Our Environment: Windows, 3 application servers total - Enterprise Guide

  • 2 VM's, one Metadata Server, one Web server
  • 1 Physical server - Compute / App server - 278GB RAM
  • C drive: 15gb free of 100GB
  • D drive: 162GB free of 179GB <--- This is where the app is installed
  • SASWORK points to E drive, which is 5TB of SAN DISK
  • Users log into Enterprise Guide via Citrix to access SAS

 

Our hardware group contacted me the other day to let me know that the C drive of the Compute server had a 55GB pagefile. C drive is normally at about 50-70% free. I realize our C drive is small, but since we were directing all SASWORK to the E drive, we were told by SAS that our configuration worked.

 

A few questions -

  • What is using the C drive if the SAS Application is installed on D, users access it via Citrix and SASWORK points to E (SAN disk)?
  • Why is the application paging if RAM is so high on the server, but heavily unused?
  • Though the recommendation for the Page File is usually 1.5X RAM, in our case, our C drive can't handle that since RAM is very high at 278GB yet the C drive is very small. The idea was that we wouldn't use C at all. How should we set our Page File size? Or should we still set the Page File to 1.5X RAM, but put it on the SANDISK?

Keep in mind that our configuration, though not ideal, was approved by SAS, so at this point, we can't just get a new server or add space to C - this server can't be expanded anymore, so if there are any other ideas on what we can configure or look at, I'd be glad to hear it!

3 REPLIES 3
SASKiwi
PROC Star

Interesting. I checked out our Windows SAS App server C drive and it has 80GB space and has 43GB free. We have never had a problem like you describe in all the years our server has been running.

 

A few thoughts. Do you do Disk Cleanups on your drives? It wouldn't do any harm to try this.

 

How often do you reboot your servers? We have ours on a monthly reboot cycle. If you are not doing regular reboots then I would suggest doing this and see if this impacts the Windows Page File.

 

This is more of a Windows issue so I'd suggest googling your problem and include the version of Windows Server you are using. Windows Server forums are likely to be more helpful.

SimonDawson
SAS Employee

Your questions are best put to your Microsoft Windows system administrators. The configuration of your Microsoft Windows virtual memory subsystem is best left to your Windows experts. For most (if not all) SAS applications you don't want any paging occurring. There is a good guide by Moti Bani from Microsoft here that I suggest you read.

 

The Windows page file is used as the dump location for all of memory if the system panics. When you have large amounts of memory this demands a larger page file.

 

> 1. What is using the C drive if the SAS Application is installed on D, users access it via Citrix and SASWORK points to E (SAN disk)?

 

The application needs the operating system to interface with the hardware. The C:\ would contain all the binaries and the kernel used by the application to interface with the physical hardware. Your sysadmins have pointed out there are key files used by the operating system like the page file that were configured by your Microsoft Windows system administrators to reside on that volume.

 

> Why is the application paging if RAM is so high on the server, but heavily unused?

 

Having a large page file on Windows does not necessarily mean the virtual memory system is paging. The performance monitor exposes the page faults/sec in Windows. That page fault/s is major and minor faults, no idea who to track major faults only. Not sure what the Windows equivalent of vmstat(1) is but I'd be sure Microsoft exposes the paging rate somewhere for users to check.

 

> Though the recommendation for the Page File is usually 1.5X RAM,

 

This was a rule of thumb some time back but has not been the case for a while. For me since the swap to 64-bit systems some 10 years ago that 1.5X RAM rule of thumb isn't something I follow.

 

 

I don't use Windows much, most of my experience is with Linux, so consider my advice with that in mind. For me personally I typically don't allocate any swap if I know I have enough memory for the application. If the kernel starts to get unstable and I need to capture crash dumps then I'll make a plan to attach some disk. For day to day running swap isn't needed when you have lots of memory.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 3 replies
  • 2188 views
  • 1 like
  • 4 in conversation