My understanding is that it won't have much impact. In case of random reads, read cache won't help much (typically low read cache hit ratio). So, changing cache parameters may not help much.
We may need to look at the drives. Maybe have more spindles serving the requests as all (or most) IO requests will be served by disks and not the cache. You may want to check with your local performance specialists before taking a decision on this.
By any chance, is it an iSCSI implementation?
VMware and Windows may gain some performance by changing the delayed ACK feature.
There are different entries for Win 2008 and 2008R2.
These values though are only for iSCSI and have no impact on FC connectivity.
Further details on IO profile and distribution on load along with your actual performance expectation will definitely get you more helpful responses regarding this.
Changing cache page size will have no effect on random read performance.
The only change you can make to cache would be for sequential read performance. In which case you would increase the percentage of system cache dedicated to read cache. This would increase the likelihood of a 'cache hit' through read ahead.
The effect of the cache on different I/O workloads is explained in the 'Memory' section of the EMC CLARiiON Storage System Fundamentals whitepaper. This document is available on Powerlink.
The quickest way to increase random read performance would be to move to faster drives. EFD drives (flash drives or SSDs) give the highest random read performance.
The thing to remember when analyzing random read performance is that due to the nature of a random read the i/o will be serviced by the disk. This means that the underlying RAID architecture of your LUN is going to be the bottleneck for performance, the array cache will not affect this. So I would analyze your RAID layout for this data set. For random reads you should be using RAID1/0 and have enough disks in the RAID set to satisfy the i/o requirements of the application.
Can you provide more information on the application and operating system? This will help with a more specific recommendation for improving performance.
I am not really a performance guy, but here is what I think.
There are 4 different Page Size Settings in Cache for the Clariion, 2 KB, 4 KB, 8 KB, and 16 KB. If we take the default Clariion Page Size of 8 KB. every "Page" in Cache will be 8 KB in size. If we have an application like Oracle running on Clariion, and Oracle using a default Block Size of 16 KB, that would mean that every Oracle Block of data to the Clariion would be broken into two separate Pages in Cache and you should see some performance impact. With SQL writing to this 8 KB Page Size, it is a one to one ratio, as it is with Exchange, however, with every Exchange Block of data, there is a 4 KB waste of space per block, which could be filling up Cache more rapidly with this "wasted space."
If we are using one application on clariion it should be rather easy to decide what should be the page size, if there are different applications there should trade off and will be having winners and loosers.
rupak1
29 Posts
0
July 22nd, 2010 13:00
My understanding is that it won't have much impact. In case of random reads, read cache won't help much (typically low read cache hit ratio). So, changing cache parameters may not help much.
We may need to look at the drives. Maybe have more spindles serving the requests as all (or most) IO requests will be served by disks and not the cache. You may want to check with your local performance specialists before taking a decision on this.
By any chance, is it an iSCSI implementation?
VMware and Windows may gain some performance by changing the delayed ACK feature.
Further read at:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002598
http://support.microsoft.com/kb/328890/
There are different entries for Win 2008 and 2008R2.
These values though are only for iSCSI and have no impact on FC connectivity.
Further details on IO profile and distribution on load along with your actual performance expectation will definitely get you more helpful responses regarding this.
-rupak
jps00
2 Intern
•
392 Posts
0
July 23rd, 2010 04:00
Changing cache page size will have no effect on random read performance.
The only change you can make to cache would be for sequential read performance. In which case you would increase the percentage of system cache dedicated to read cache. This would increase the likelihood of a 'cache hit' through read ahead.
The effect of the cache on different I/O workloads is explained in the 'Memory' section of the EMC CLARiiON Storage System Fundamentals whitepaper. This document is available on Powerlink.
The quickest way to increase random read performance would be to move to faster drives. EFD drives (flash drives or SSDs) give the highest random read performance.
AranH1
2.2K Posts
0
July 23rd, 2010 07:00
Vincent,
The thing to remember when analyzing random read performance is that due to the nature of a random read the i/o will be serviced by the disk. This means that the underlying RAID architecture of your LUN is going to be the bottleneck for performance, the array cache will not affect this. So I would analyze your RAID layout for this data set. For random reads you should be using RAID1/0 and have enough disks in the RAID set to satisfy the i/o requirements of the application.
Can you provide more information on the application and operating system? This will help with a more specific recommendation for improving performance.
Aran
robi_88c571
21 Posts
0
July 23rd, 2010 08:00
I am not really a performance guy, but here is what I think.
There are 4 different Page Size Settings in Cache for the Clariion, 2 KB, 4 KB, 8 KB, and 16 KB. If we take the default Clariion Page Size of 8 KB. every "Page" in Cache will be 8 KB in size. If we have an application like Oracle running on Clariion, and Oracle using a default Block Size of 16 KB, that would mean that every Oracle Block of data to the Clariion would be broken into two separate Pages in Cache and you should see some performance impact. With SQL writing to this 8 KB Page Size, it is a one to one ratio, as it is with Exchange, however, with every Exchange Block of data, there is a 4 KB waste of space per block, which could be filling up Cache more rapidly with this "wasted space."
If we are using one application on clariion it should be rather easy to decide what should be the page size, if there are different applications there should trade off and will be having winners and loosers.