BookmarkSubscribeRSS Feed
againreddy
Obsidian | Level 7

Hi All,

 

We have users do the heavy sorting and proc steps ... Our /saswork space is 500gb on SSD. The users experiencing  more more IO time .(more than 75% of CPU time). One of the recommendation was to add a separate drive for /sasutil .  Please advice me on how much /sasutil space is needed when the /saswork is 500gb.  

 

Please advice.

2 REPLIES 2
jklaverstijn
Rhodochrosite | Level 12

That's a very difficult question to answer without knowing your data. You are asking for performance but not telling about your space requirements. Is your 500GB sufficient? You may want to start with UTIL equal to WORK and monitor closely. Be prepared to add when you see your space being consumed totally.

 

What strikes me is what seems like a rather high WAIT-FOR-IO percentage. If it is 75%, you may have an issue that will not likely be completely solved by adding separate UTIL space. I know it is a recommended configuration and it will help, but when applied in a system where I/O is constrained like yours seems to be the I/O throughput to UTIL will likely also be less than desired. Look at other bottlenecks first. Do you use striping/RAID? WORK/UTIL do not usually require the resiliance of a RAID5, 6 or 10 like the locations where your data is stored. RAID2 can give you the performance boost you're looking for. A single SAS or SATA channel to an SSD is still a bottleneck so consider spreading out over multiple channels. Divide and conquer. Look at the complete storage architecture and then decide to split WORK and UTIL. And keep them local, on a SAN or on a special purpose shared storage system like GPFS. Never use a NAS with NFS or CIFS (Windows shares). Not even a fancy Scale-out NAS, no matter what the sales people tell you. Just don't. Ever. Tell them I told you so. Do throughput benchmark tests outside of SAS. There are many (open source) utilities  Look at large blocksizes (>256k) with a 50/50 read-write ratio. Also look for high throughput rather than high IOPS.

 

SAS is very I/O intense and tuning your I/O needs careful consideration. It can become cumbersome and expensive, but also very rewarding. Embark on a journey and do not expect quick returns. But they can be big.

 

Hope this helps,

- Jan.

Kurt_Bremser
Super User

To add to what @jklaverstijn said, don't use any kind of "remote" storage for WORK/UTIL. If you are running on a virtualized server where all storage is supplied by a SAN, that SAN should be capable of at least 500MB/sec for your SAS server alone. That translates to two 4Gbit optical interface cards working in parallel.

If no SAN, WORK and UTIL should be separate, striped high-speed disksets installed internally.

 

And of course take a look at the I/O subsystem of your server. Don't be surprised to run into I/O bottlenecks on standard PC hardware.

Multiple fibre channel interfaces are of no use if they have to contend for the bandwidth of a single PCI bus, for instance.

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 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 2 replies
  • 1342 views
  • 3 likes
  • 3 in conversation