BookmarkSubscribeRSS Feed
rkamuru
Calcite | Level 5

I had discussed with SAS team earlier regarding SAS work space file system. They said local should be used. We are seeing few cases where Network file system is performing better than local file system. Any recommendations??

4 REPLIES 4
Reeza
Super User
I would assume moving files around always takes longer. Are the files smaller or compressed? Are you testing this with cleaning any cached data?
And monitoring other activity on the server?
Kurt_Bremser
Super User

@rkamuru wrote:

I had discussed with SAS team earlier regarding SAS work space file system. They said local should be used. We are seeing few cases where Network file system is performing better than local file system. Any recommendations??


Throw out your crappy local disks and replace them with something adequate (4 striped SSD's, for example). If "local" means a single spinning metal disk, it can't compete with a modern array of SSD's in your NAS.

AhmedAl_Attar
Ammonite | Level 13

Hi @rkamuru 

 

Check the relevant link to your Operating System from this page "Usage Note 53876: Troubleshooting system performance problems: Testing I/O throughput"

Follow the listed instructions to test/ the throughput of your file system. This would be your go to matrix

 

Hope this helps,

Ahmed  

JuanS_OCS
Amethyst | Level 16

Hello @rkamuru ,

 

this is a very interesting question. What you describe can perfectly happen, and it depends on many variables. 

Perhaps I would like to hear from you some details such as: are we talking about on-premises or a cloud infrastructure, if it is a cloud, which one, and what flavor of storage are we using locally, what shared file sytem is in use and the storage provided to this shared file system.

 

Here is the thing:

  • The best practice is, generally speaking, to set up local storage. This is correct. The main reasons are simple: local storage prevents slowness due to network, and traffic is local/dedicated, no external interference.
  • However, there might be always exceptions that are very important to be considered, where the best practice cannot be applied unfortunately. Some of those can be: good enough local storage cannot be allocated, the RAID configuration, or the storage, even if fully stripped according to all recommendations, cannot provide the expected performance (the sum of throughput). In this case, why not look for alternatives.

Actually, when SASWORK requires certiain persistance and has to be shared across nodes (SAS session failover option for SAS grid), SASWORK must be placed in a shared storage, SAS session failover cannot happen with local storage, as SAS sessions from the different grid nodes will need to have the SASWORK available from one node to the rest.

 

This being said: if you place SASWORK in shared storage, it will be critical to run an assessment. Are there other applications/clients connecting to this shared storage, or to its network? It is important to run the proper calculations and to test the workload on throughput, a real stress test.Then as well, an overal cost assessment.

 

Consider as well, that the calculation of the throughput through the network could probably force you to oversize some parts of your design (more cores than needed, more ram, more disks, etc etc) and one of them will be your bottleneck. But you can choose as well which one will it be, specially based on costs vs budget.

 

All in all, if you the balance from Pros vs Cons go to Pros to the shared storage, I would give it a go.

 

I hope it helps.

Best regards,

Juan

 

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 

Discussion stats
  • 4 replies
  • 1090 views
  • 6 likes
  • 5 in conversation