Performance Acceleration Module
Sep 30th 2008Unitek NetApp BlogUncategorized
Since I come from a bit of a database background, I often look at storage performance through a DBA’s lense. I looked askance at the trend toward ever large disk drives. More spindles mean better performance and drive capacity has been growing much faster than performance.
In the database world, one of the ways we deal with this problem is with a large memory cache. (In Oracle, this cache is called the SGA). Ideally, most database read requests can be satisfied from local cache memory. Not only does this dramatically reduce latency on read requests but this load is removed from the storage system so it can use the freed bandwidth for other operations. Obviously, this doesn’t work for every workload but makes a dramatic difference in many common situations.
For other workloads the problem is not so easily solved. We depend on the memory and read algorithms of the storage system. But what if these are not enough? In the past we have not been able to increase the RAM in a Netapp storage controller, so our only real option to increase the performance of the storage system has been to increase the number of drives and spread the load across more spindles. This may be expensive, not only in terms of initial cost, but also in cooling and electrical requirements.
So Netapp has come up with a solution. It’s called PAM, for Performance Acceleration Module. PAM is a PCIe card with 16GB of DDR2 SDRAM. It is integrated into Data ONTAP with a new technology called FlexScale. FlexScale is a license product. To implement PAM requires both the hardware and a license.
Basically PAM extends Data ONTAP’s read cache. It will have the greatest impact on highly random file intensive workloads such as home directories, but it should improve performance in a wide variety of situations.
Three different algorithms are supported. The default mode works basically as an extension of Data ONTAP’s normal read cache. In this mode both data and metadata are cached.
The second algorithm caches only metadata on the accelerator. This may be more effective with workloads where data is not re-accessed, but the metadata may be reused. This may also be effective with large working sets that are too large to fit in memory but the set of metadata associated to it will be accommodated.
Finally, there is something called Low-Priority mode. This causes data that the standard algorithms discard to be saved in memory. Normally this data is discarded to prevent it from pushing higher value data (data more likely to be re-used) from being pushed out of the cache. If the access pattern is such that data is commonly reused after a time lag, this may be effective.
Different storage systems support different numbers of PAMs, with the larger systems able to use more of them.
If this sounds interesting to you, here is a link to get more information.
































