4. How much SSD cache is exactly right for my Application ? – Application Data Cache Sizing with PerfAccel Analytical Mode

Till now, we have gone through various Analytical metrics provided by PerfAccel. We have also seen different kinds of Synthetic workload runs and their Analytical information including the metric “Amount of data cached”. Now-a-days, inspite of being expensive, SSDs are very popular as compared to their SATA/SAS counterparts in terms of $/GB and Perf/$. But, the first and most important question before any Storage admin is always “How much SSD ?” “Shall we spend on a 128GB or 256GB or even higher capacity SSD ?”. Let’s see how PerfAccel helps us here by providing the correct answer even before they decide to Spend $$$ on the SSDs.

Unfortunately our Applications do not have the privilege of storing all of their data on SSDs. Even if we get a 1TB SSD, then we need to manually copy the whole Application data into the SSD, which may be large, for ex. say 500 GB or 800 GB or even more. Now, it is a very common scenario where most of the Application workloads access only a part of the whole dataset. Suppose, our Application has 800GB of data but works on, say, only 100GB of the files scattered throughout. In this case, copying all of the 800 GB of data is a pure waste i.e. 700 GB of expensive SSD space is wasted and simply blocked from others using it. This could have been utilized for the working set data of 4-5 other Applications.

This is where PerfAccel provides a disrupting, game-changing solution by intelligently managing & placing only the HOT DATA on the SSD. This means only the 100GB of data that is really accessed by the Application will be placed dynamically & automatically on the SSD by PerfAccel. It also facilitates other Applications to use the remaining cache space  in a seamless manner without disturbing the first application. And no manual data movement to the SSD is necessary. PerfAccel does everything automatically.

Now, the question that comes is, how do we decide what size of SSD to purchase ? 128 GB, 256 GB, 512 GB , 1TB or even more ? Well, PerfAccel considers this as one of the most important aspects of Caching & Analytics and recommends users to find the answer much before even thinking about spending a dollar on SSDs. And to help users in finding the correct size, PerfAccel provides the Special Analytical Mode of Caching. With this mode we can have a Virtual Cache of size upto 4TB with just a small 100GB of SATA/SAS disk or any similar disk.

This mode is very helpful in understanding the working set characteristics of the application and in sizing the high performance cache device for the Application workload much before actually investing in a real SSD. Analytical mode helps predict the optimal size of the cache device for the compute grid environment and avoids expensive over provisioning or bad under provisioning.

Apart from sizing feature, its other major objective is to Provide I/O Analytics or I/O behavior of the Application at multiple levels of granularity.

How to find the cache size ?

The process for Sizing /finding the Working set size of any Application is super-simplified by PerfAccel

It’s as simple as described below:

  1. Create an Analytical Source for the Application data directory and assign the amount of virtual cache space that you think may be the maximum amount needed. its an approximate estimated value. If your are not sure, then assign the Max virtual cache of 4TB (yes 4TB….even though we have a smaller disk here, with PerfAccel you can have a 4TB virtual cache 🙂 )
  2. Then run the Application Workload
  3. Once the workloads complete, you can verify the various I/O traces to find out how much cache has been utilized by the workload runs. – “Cache Usage Trace” , “Cache Cleanup Trace”,  “Cache IO Trace”,  “Cache Brief Trace”  etc.
  4. You can re-run the Application workload and verify that the cache usage stays around the same size and also see how the cache is being hit during the Job run
  5. If Cache Evictions are triggered by PerfAccel, then it means that Cache Size is not sufficient. In that case, the cache size has to be increased further and workload re-run (So, here if the Virtual size of 4TB is used, then no Evictions will be triggered [unless you really have a working set size more than 4TB 🙂 ] and we won’t come to this step)
  6. If the cache usage turns out to say  200GB, then you can safely go for a 256 GB SSD , as its clear from the Usage Traces that Application workload is not going to use more than 200GB.

This was for 1 application. If you have multiple applications, then do the same thing i.e. create Analytical Sources for each of them and assign Max Virtual Cache and run the respective workloads. At the end, you can sum up the total cache usage from all the Sources. This final value is maximum amount of working set size of all the Applications. You should purchase a SSD with capacity slightly more than this.

So, here PerfAccel helped you save some  $$$  on the SSD straightaway. We will now see a demo of the above process to make the whole process very clear. So, lets create our cache first.

# dgpctl -cache create sata_cache /dev/md127  -f
Initializing cache device /dev/md127. This operation can take several minutes. Please wait...
Cache sata_cache successfully created

# dgpctl -cache list
Device        Total size   Free size  Alloc size  State    IP address      Name      
/dev/md127       35.4 GB     35.3 GB      0.0 MB  Online   192.168.1.38    sata_cache

Now, we will create an Analytical Source instead of the Regular Writethrough Source. The Analytical Source needs a cache with atleast 25GB of space. (Though we can override this with a lower value with -f, but Datagres does not recommend doing so)

The Analytical source can be created by using the option “-o analytical” in the source creation command

We will see both the cases i.e. Limited Cache Size and Unlimited Cache size

Case 1 – Analytical source with limited cache size

# dgpctl -source create app_data /app_data -o analytical sata_cache 25G
Source app_data was successfully created
Adding cache to analytical-source app_data can take time. Please wait...
[###################################################]
25G of cache from sata_cache successfully added to source app_data


# dgpctl -source list
Source                           Status       Cache           Size       Mount Point     Type       Mode
app_data                         ONLINE       sata_cache      25.0 GB    /app_data       nfs        WT(A) 

WT(A) means Writethrough Analytical Source

Case 2 – Analytical source with Infinite virtual cache (4TB)

This is the most preferred mode, where we want to Fingerprint Application I/O workload and we are not sure about its I/O profile, working set size etc. For that we need to provide “max” as the Cache Size in the source creation command

# dgpctl -source create app_data /app_data -o analytical sata_cache max

Source app_data was successfully created
Adding cache to analytical-source app_data can take time. Please wait...
[###################################################]
4.0 TB of cache from sata_cache successfully added to source app_data

# dgpctl -source list
Source                           Status       Cache           Size       Mount Point     Type       Mode
app_data                         ONLINE       sata_cache      4.0 TB     /app_data       nfs        WT(A)

We can see here clearly that Cache space allocated to the source is 4TB

Now, lets proceed with this source. And lets run a workload. We will use filebench again to generate the workload. This time we will use the Webserver profile of filebench.

The workload generation will happen covering 200000 files and will run for 2000 secs.

At this point we are not sure of how much cache size this workload requires. Neither does any utility exists out there which can tell us about the Working set size information. (Does it ??? Reply in comments 🙂 ).  But, don’t worry, we have PerfAccel with us. Lets wait for the test to end and we will go through the cache sizing details. The data generation will take a lot of time as its going to create 200000 files over the NFS share. Then the test will run for 2000 secs

# filebench 
Filebench Version 1.4.9.1
 6677: 0.000: Allocated 170MB of shared memory
filebench> load webserver
 6677: 2.399: Web-server Version 3.0 personality successfully loaded
 6677: 2.399: Usage: set $dir=<dir>
 6677: 2.399:        set $meanfilesize=<size>   defaults to 16384
 6677: 2.399:        set $nfiles=<value>    defaults to 1000
 6677: 2.399:        set $meandirwidth=<value>  defaults to 20
 6677: 2.399:        set $nthreads=<value>  defaults to 100
 6677: 2.399:        set $iosize=<size>     defaults to 1048576
 6677: 2.399:        run runtime (e.g. run 60)
filebench> set $dir=/app_data
filebench> set $nfiles=200000
filebench> set $iosize=2097152
filebench> set $meandirwidth=40
filebench> run 2000
 6677: 52.181: Creating/pre-allocating files and filesets
 6677: 52.428: Fileset logfiles: 1 files, 0 leafdirs, avg dir width = 40, avg dir depth = 0.0, 0.002MB
 6677: 52.434: Removed any existing fileset logfiles in 1 seconds
 6677: 52.434: making tree for filset /app_data/logfiles
 6677: 52.868: Creating fileset logfiles...
 6677: 52.937: Preallocated 1 of 1 of fileset logfiles in 1 seconds
 6677: 53.078: Fileset bigfileset: 200000 files, 0 leafdirs, avg dir width = 40, avg dir depth = 3.3, 3127.563MB
 6677: 53.080: Removed any existing fileset bigfileset in 1 seconds
 6677: 53.080: making tree for filset /app_data/bigfileset
 6677: 60.138: Creating fileset bigfileset...
 6677: 7311.549: Preallocated 200000 of 200000 of fileset bigfileset in 7252 seconds
 6677: 7311.573: waiting for fileset pre-allocation to finish
10811: 7311.638: Starting 1 filereader instances
10812: 7311.797: Starting 100 filereaderthread threads
 6677: 7314.847: Running...
 6677: 9334.384: Run took 2000 seconds...
 6677: 9335.082: Per-Operation Breakdown

appendlog            49526ops       25ops/s   0.2mb/s      5.2ms/op     9662us/op-cpu [0ms - 1996ms]
closefile10          49426ops       24ops/s   0.0mb/s      0.0ms/op     7733us/op-cpu [0ms - 6ms]
readfile10           49433ops       24ops/s   0.4mb/s     88.6ms/op    52858us/op-cpu [0ms - 4659ms]
openfile10           49437ops       24ops/s   0.0mb/s    279.9ms/op   131318us/op-cpu [0ms - 10864ms]
closefile9           49440ops       24ops/s   0.0mb/s      0.0ms/op     7920us/op-cpu [0ms - 14ms]
readfile9            49443ops       24ops/s   0.4mb/s     88.7ms/op    52489us/op-cpu [0ms - 5611ms]
openfile9            49448ops       24ops/s   0.0mb/s    280.6ms/op   130452us/op-cpu [0ms - 9750ms]
closefile8           49449ops       24ops/s   0.0mb/s      0.0ms/op     7869us/op-cpu [0ms - 11ms]
readfile8            49454ops       24ops/s   0.4mb/s     89.5ms/op    52804us/op-cpu [0ms - 4671ms]
openfile8            49456ops       24ops/s   0.0mb/s    280.7ms/op   131669us/op-cpu [0ms - 8960ms]
closefile7           49458ops       24ops/s   0.0mb/s      0.0ms/op     7780us/op-cpu [0ms - 16ms]
readfile7            49462ops       24ops/s   0.4mb/s     89.8ms/op    52956us/op-cpu [0ms - 4664ms]
openfile7            49463ops       24ops/s   0.0mb/s    285.0ms/op   131463us/op-cpu [0ms - 10846ms]
closefile6           49465ops       24ops/s   0.0mb/s      0.0ms/op     7965us/op-cpu [0ms - 7ms]
readfile6            49468ops       24ops/s   0.4mb/s     89.9ms/op    53403us/op-cpu [0ms - 4983ms]
openfile6            49468ops       24ops/s   0.0mb/s    284.1ms/op   132923us/op-cpu [0ms - 10832ms]
closefile5           49471ops       24ops/s   0.0mb/s      0.0ms/op     7810us/op-cpu [0ms - 8ms]
readfile5            49475ops       24ops/s   0.4mb/s     88.9ms/op    52889us/op-cpu [0ms - 6445ms]
openfile5            49478ops       24ops/s   0.0mb/s    279.0ms/op   131301us/op-cpu [0ms - 9938ms]
closefile4           49484ops       24ops/s   0.0mb/s      0.0ms/op     7934us/op-cpu [0ms - 9ms]
readfile4            49485ops       24ops/s   0.4mb/s     89.0ms/op    52951us/op-cpu [0ms - 5613ms]
openfile4            49489ops       25ops/s   0.0mb/s    281.6ms/op   132055us/op-cpu [0ms - 10787ms]
closefile3           49495ops       25ops/s   0.0mb/s      0.0ms/op     7771us/op-cpu [0ms - 25ms]
readfile3            49498ops       25ops/s   0.4mb/s     88.0ms/op    52462us/op-cpu [0ms - 4663ms]
openfile3            49502ops       25ops/s   0.0mb/s    286.1ms/op   132585us/op-cpu [0ms - 10838ms]
closefile2           49504ops       25ops/s   0.0mb/s      0.0ms/op     7840us/op-cpu [0ms - 18ms]
readfile2            49505ops       25ops/s   0.4mb/s     89.1ms/op    52909us/op-cpu [0ms - 5206ms]
openfile2            49513ops       25ops/s   0.0mb/s    287.4ms/op   132520us/op-cpu [0ms - 10844ms]
closefile1           49513ops       25ops/s   0.0mb/s      0.0ms/op     7752us/op-cpu [0ms - 26ms]
readfile1            49515ops       25ops/s   0.4mb/s     91.1ms/op    52436us/op-cpu [0ms - 4668ms]
openfile1            49522ops       25ops/s   0.0mb/s    293.6ms/op   133427us/op-cpu [0ms - 10847ms]
 6677: 9335.082: IO Summary: 1533745 ops, 759.304 ops/s, (245/25 r/w),   4.0mb/s,   1325us cpu/op, 339.6ms latency
 6677: 9335.082: Shutting down processes

Ok. Workload has completed Let’s get the Analytical Traces

Cache IO Trace

# dgpctl -cache trace io
---------------------------------------------------------------------------------------------------
    c-read    c-write      s-read    s-write   sys-read  sys-write      s-name            s-dir  
---------------------------------------------------------------------------------------------------
    5.1 GB   256.0 KB      3.4 GB     3.8 GB     1.9 TB     1.6 GB      app_data          /app_data      

Cache Usage Trace

# dgpctl -cache trace usage
-----------------------------------------------------------------------------------------------------------------
        size          usage  use%      max usage            nfiles            ndirs   source name     source dir  
----------------------------------------------------------------------------------------------------------------
        4.0 TB         8.4 GB  0.2%        8.4 GB            200001                0   app_data         /app_data 

Cache Cleanup/Eviction Trace

# dgpctl -cache trace cleanup
--------------------------------------------------------------------------------------------------
Cleanup Runs     Last Freed    Total Freed   TotalMetaFreed    Source Name              Source Dir
--------------------------------------------------------------------------------------------------
           0         0.0 KB         0.0 KB           0.0 KB    app_data                 /app_data   

Brief Trace

# dgpctl -cache trace brief app_data
-----------------------------------------------------------
	      * app_data: PERFACCEL CACHE STATISTICS * 
-----------------------------------------------------------
Files In Cache		 : 200001
File Segments Cached	 : 200001
File Segments Uncached	 : 0
File Segments Present	 : 200001
Read Hits		 : 1328672
Read Misses		 : 901765
Write Misses		 : 1000318
Write Hits		 : 64
Writeback Hits		 : 0
Attribute Read Hits	 : 0
Attribute Read Misses	 : 5055
Attribute Write Hits	 : 0
Attribute Write Misses	 : 0
Links Cached		 : 0
Link Hits		 : 0
Link Misses		 : 0
Link Cache Usage	 : 0.0 KB
Directories cached	 : 0
Directories uncached	 : 0
ReadDir Hits		 : 0
ReadDir Misses		 : 0
Dir Attribute Read Hits	 : 0
Dir Attribute Read Misses: 0
Directories Cache Usage	 : 0.0 KB
Total Cache Usage	 : 8.4 GB (0.21%)
Source Cache Capacity	 : 4.0 TB
Pending I/O requests	 : 0
Misses During Cacheify	 : 0
Max Cache Usage		 : 8.4 GB
Total Cacheify		 : 0.0 KB
File Cache Limit	 : 100%
Cache Uptime		 : 3 hrs 10 mins 52 secs

Cacheify Failure Reasons
------------------------
Count of Not Enough Space: 0
Cleaner In Progress	 : 0
-----------------------------------------------------------
	      * CLEANUP STATISTICS *		
-----------------------------------------------------------
Total cleanup runs	 : 0
Last cleanup run at	 : 0
Total chunks thrown	 : 0
Time taken for last run	 : 0 sec
Last run freed space	 : 0.0 KB
Total freed space	 : 0.0 KB
Total Time in cleaner	 : 0 sec
Total Time in bucketize	 : 0 sec
Evict fail due to flush	 : 0
Evict fail due to other	 : 0
TTL Expiry Eviction	 : 0 (Segments)
Eviction Meta Freed	 : 0.0 KB
-----------------------------------------------------------
	      * WRITEBACK STATISTICS *		  
-----------------------------------------------------------
Pending Attribute Flush	 : 0
Bytes Pending Writeback	 : 0.0 KB
Data scheduled for flush : 0.0 KB
Total Bytes Flushed	 : 0.0 KB
-----------------------------------------------------------
	      * LAST FLUSH STATISTICS *	    
-----------------------------------------------------------
Flush ID		 : 0 
Scheduling time		 : 0.00 sec
IO time			 : 0.00 sec
Bytes Flushed		 : 0.0 KB
-----------------------------------------------------------

Meta Ops Trace

# dgpctl -cache trace meta
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  l-cached     l-hits   l-misses   cr-attr    cw-attr    sr-attr    sw-attr     create       open      close     unlink      fsync     frdlck     fwrlck       mmap        s-name          s-dir  
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   0              0         0         0          0         5055        0         200001     694877     694877      0            0         0          0        158082         app_data     /app_data 

With the above traces, we can easily conclude that our workload :

  1. Does not need more than 10 GB of cache space 
  2. Does more re-reads after writing for the first time. So, its a good candidate for caching
  3. Is Read Intensive workload
  4. Does not trigger any evictions/cleaups, again proving that the cache size needed for it is anything around 10GB
  5. Created around 200000 new files
  6. Is I/O intensive rather than Attribute or Meta Operation intensive, as the Attribute misses/hits are very less compared to the number of files
  7. Does a good amount of mmaps

Now, lets run the workload once more. This time it will re-use the files already created earlier and perform only the I/O for 2000 secs

filebench> load webserver
13166: 2.618: Web-server Version 3.0 personality successfully loaded
13166: 2.618: Usage: set $dir=<dir>
13166: 2.618:        set $meanfilesize=<size>   defaults to 16384
13166: 2.618:        set $nfiles=<value>    defaults to 1000
13166: 2.619:        set $meandirwidth=<value>  defaults to 20
13166: 2.619:        set $nthreads=<value>  defaults to 100
13166: 2.619:        set $iosize=<size>     defaults to 1048576
13166: 2.619:        run runtime (e.g. run 60)
filebench> set $dir=/app_data
filebench> set $nfiles=200000
filebench> set meandirwidth=40
13166: 16.551: syntax error at 'meandirwidth' on line 86
filebench> set $meandirwidth=40
filebench> run 2000
13166: 27.990: Creating/pre-allocating files and filesets
13166: 28.003: Fileset logfiles: 1 files, 0 leafdirs, avg dir width = 40, avg dir depth = 0.0, 0.002MB
13166: 28.003: Re-using fileset logfiles.
13166: 28.004: Creating fileset logfiles...
13166: 28.130: Preallocated 1 of 1 of fileset logfiles in 1 seconds
13166: 28.331: Fileset bigfileset: 200000 files, 0 leafdirs, avg dir width = 40, avg dir depth = 3.3, 3127.563MB
13166: 28.331: Re-using fileset bigfileset.
13166: 28.331: Creating fileset bigfileset...
13166: 178.497: Preallocated 200000 of 200000 of fileset bigfileset in 151 seconds
13166: 178.498: waiting for fileset pre-allocation to finish
13249: 178.498: Starting 1 filereader instances
13250: 178.561: Starting 100 filereaderthread threads
13166: 185.665: Running...
13166: 2202.327: Run took 2000 seconds...
13166: 2202.487: Per-Operation Breakdown
appendlog            55055ops       27ops/s   0.2mb/s      4.8ms/op    11660us/op-cpu [0ms - 1369ms]
closefile10          54956ops       27ops/s   0.0mb/s      0.0ms/op     8926us/op-cpu [0ms - 18ms]
readfile10           54959ops       27ops/s   0.4mb/s     78.8ms/op    57426us/op-cpu [0ms - 4978ms]
openfile10           54963ops       27ops/s   0.0mb/s    244.3ms/op   137155us/op-cpu [0ms - 6145ms]
closefile9           54964ops       27ops/s   0.0mb/s      0.0ms/op     9263us/op-cpu [0ms - 18ms]
readfile9            54972ops       27ops/s   0.4mb/s     79.6ms/op    57736us/op-cpu [0ms - 4603ms]
openfile9            54974ops       27ops/s   0.0mb/s    247.6ms/op   137304us/op-cpu [0ms - 5983ms]
closefile8           54976ops       27ops/s   0.0mb/s      0.0ms/op     9364us/op-cpu [0ms - 31ms]
readfile8            54983ops       27ops/s   0.4mb/s     79.4ms/op    57374us/op-cpu [0ms - 4969ms]
openfile8            54986ops       27ops/s   0.0mb/s    245.9ms/op   136088us/op-cpu [0ms - 5649ms]
closefile7           54989ops       27ops/s   0.0mb/s      0.0ms/op     8996us/op-cpu [0ms - 17ms]
readfile7            54994ops       27ops/s   0.4mb/s     79.5ms/op    57476us/op-cpu [0ms - 5229ms]
openfile7            54997ops       27ops/s   0.0mb/s    245.5ms/op   136647us/op-cpu [0ms - 6114ms]
closefile6           55001ops       27ops/s   0.0mb/s      0.0ms/op     9253us/op-cpu [0ms - 5ms]
readfile6            55003ops       27ops/s   0.4mb/s     79.9ms/op    57802us/op-cpu [0ms - 5065ms]
openfile6            55004ops       27ops/s   0.0mb/s    242.7ms/op   136958us/op-cpu [0ms - 5642ms]
closefile5           55006ops       27ops/s   0.0mb/s      0.0ms/op     9149us/op-cpu [0ms - 16ms]
readfile5            55008ops       27ops/s   0.4mb/s     78.8ms/op    57426us/op-cpu [0ms - 5176ms]
openfile5            55011ops       27ops/s   0.0mb/s    243.6ms/op   136690us/op-cpu [0ms - 6174ms]
closefile4           55012ops       27ops/s   0.0mb/s      0.0ms/op     9276us/op-cpu [0ms - 17ms]
readfile4            55016ops       27ops/s   0.4mb/s     80.1ms/op    57740us/op-cpu [0ms - 5062ms]
openfile4            55020ops       27ops/s   0.0mb/s    245.6ms/op   137240us/op-cpu [0ms - 5883ms]
closefile3           55023ops       27ops/s   0.0mb/s      0.0ms/op     9333us/op-cpu [0ms - 9ms]
readfile3            55036ops       27ops/s   0.4mb/s     80.3ms/op    57239us/op-cpu [0ms - 5020ms]
openfile3            55039ops       27ops/s   0.0mb/s    249.5ms/op   137239us/op-cpu [0ms - 6166ms]
closefile2           55042ops       27ops/s   0.0mb/s      0.0ms/op     8956us/op-cpu [0ms - 12ms]
readfile2            55043ops       27ops/s   0.4mb/s     81.6ms/op    57566us/op-cpu [0ms - 4732ms]
openfile2            55043ops       27ops/s   0.0mb/s    252.2ms/op   137720us/op-cpu [0ms - 5795ms]
closefile1           55044ops       27ops/s   0.0mb/s      0.0ms/op     9233us/op-cpu [0ms - 31ms]
readfile1            55051ops       27ops/s   0.4mb/s     81.1ms/op    57267us/op-cpu [0ms - 5229ms]
openfile1            55052ops       27ops/s   0.0mb/s    257.4ms/op   140034us/op-cpu [0ms - 6185ms]
13166: 2202.487: IO Summary: 1705222 ops, 845.576 ops/s, (273/27 r/w),   4.5mb/s,   1408us cpu/op, 298.0ms latency
13166: 2202.487: Shutting down processes

Ok. Its done now.

We have run the test again on the pre-created files. So, this time the workload simply ran doing its I/O. Let’s see how many of our conclusions derived after the first run still hold true :

  1. Does not need more than 10 GB of cache space – True, usage is still 8.4 GB only
  2. Does more re-reads after writing for the first time. So, its a good candidate for caching – True, in this run there was almost 100% read hits from the cache
  3. Is Read Intensive – True, writes/re-writes are almost none
  4. Does not trigger any evictions, again proving that the cache size needed for it is around 10GB – True – No evictions now as well
  5. Created around 200000 new files – False, No new files were created in this 2nd run
  6. Is I/O intensive rather than Attribute or Meta Operation intensive, as the Attribute misses/hits are very less compared to the number of files – True, only 200001 Attribute Read Hits i.e. 1 for each file
  7. Did a good amount of mmap – Still True


IO Trace

# dgpctl -cache trace io
---------------------------------------------------------------------------------------------------
    c-read    c-write      s-read    s-write   sys-read  sys-write      s-name            s-dir  
---------------------------------------------------------------------------------------------------
   14.5 GB   512.0 KB      3.4 GB     4.2 GB     2.9 TB     2.1 GB      app_data          /app_data      

Cache Usage Trace

# dgpctl -cache trace usage
-----------------------------------------------------------------------------------------------------------------
          size          usage  use%     max usage            nfiles            ndirs   source name   	source dir  
-----------------------------------------------------------------------------------------------------------------
        4.0 TB         8.4 GB  0.2%        8.4 GB            200001                0   app_data         /app_data   

Cache Cleanups/Eviction Trace

# dgpctl -cache trace cleanup
--------------------------------------------------------------------------------------------------
Cleanup Runs     Last Freed    Total Freed   TotalMetaFreed    Source Name              Source Dir
--------------------------------------------------------------------------------------------------
           0         0.0 KB         0.0 KB           0.0 KB    app_data                 /app_data      

Meta Ops Trace

# dgpctl -cache trace meta
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  l-cached     l-hits   l-misses   cr-attr    cw-attr    sr-attr    sw-attr     create       open      close     unlink      fsync     frdlck     fwrlck       mmap     s-name          s-dir  
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
         0          0          0    200001          1       5066          0     200001    1445074    1445074          0          0          0          0     358083     app_data        /app_data 

PerfAccel Brief Trace

# dgpctl -cache trace brief app_data

-----------------------------------------------------------
	      * app_data: PERFACCEL CACHE STATISTICS * 
-----------------------------------------------------------
Files In Cache		 : 200001
File Segments Cached	 : 200001
File Segments Uncached	 : 0
File Segments Present	 : 200001
Read Hits		 : 3808977
Read Misses		 : 901765
Write Misses		 : 1110199
Write Hits		 : 128
Writeback Hits		 : 0
Attribute Read Hits	 : 200001
Attribute Read Misses	 : 5067
Attribute Write Hits	 : 1
Attribute Write Misses	 : 0
Links Cached		 : 0
Link Hits		 : 0
Link Misses		 : 0
Link Cache Usage	 : 0.0 KB
Directories cached	 : 0
Directories uncached	 : 0
ReadDir Hits		 : 0
ReadDir Misses		 : 0
Dir Attribute Read Hits	 : 0
Dir Attribute Read Misses: 0
Directories Cache Usage	 : 0.0 KB
Total Cache Usage	 : 8.4 GB (0.21%)
Source Cache Capacity	 : 4.0 TB
Pending I/O requests	 : 0
Misses During Cacheify	 : 0
Max Cache Usage		 : 8.4 GB
Total Cacheify		 : 0.0 KB
File Cache Limit	 : 100%
Cache Uptime		 : 3 hrs 50 mins 55 secs

Cacheify Failure Reasons
------------------------
Count of Not Enough Space: 0
Cleaner In Progress	 : 0
-----------------------------------------------------------
	      * CLEANUP STATISTICS *		
-----------------------------------------------------------
Total cleanup runs	 : 0
Last cleanup run at	 : 0
Total chunks thrown	 : 0
Time taken for last run	 : 0 sec
Last run freed space	 : 0.0 KB
Total freed space	 : 0.0 KB
Total Time in cleaner	 : 0 sec
Total Time in bucketize	 : 0 sec
Evict fail due to flush	 : 0
Evict fail due to other	 : 0
TTL Expiry Eviction	 : 0 (Segments)
Eviction Meta Freed	 : 0.0 KB
-----------------------------------------------------------
	      * WRITEBACK STATISTICS *		  
-----------------------------------------------------------
Pending Attribute Flush	 : 0
Bytes Pending Writeback	 : 0.0 KB
Data scheduled for flush : 0.0 KB
Total Bytes Flushed	 : 0.0 KB
-----------------------------------------------------------
	      * LAST FLUSH STATISTICS *	    
-----------------------------------------------------------
Flush ID		 : 0 
Scheduling time		 : 0.00 sec
IO time			 : 0.00 sec
Bytes Flushed		 : 0.0 KB
-----------------------------------------------------------

So, with the 1st and 2nd round of conclusions, we can arrive at the fact that this particular workload can be satisfied with a small cache size i.e. around 10GB. To handle future/unknown scenarios where the workload gets affected by new conditions, lets add a 10GB more to the size, making it 20GB.  So, 20GB of cache space is good enough for this workload. Now, we can create a Write through source with SSD cache of 20GB for getting the Caching as well as Analytics benefits from PerfAccel

Its very clear how PerfAccel has simplified the whole process for finding out the Cache space Sizing information of any Application/Workload. PerfAccel Analytical mode is not only used for Sizing. It can also be used for I/O Fingerprinting an Application, without using any Real SSD as well. PerfAccel is definitely a powerful tool in the world of Next generation Storage Analytics

Now we know how to find the Cache Sizing of any Application using PerfAccel. But, what would happen if we still go ahead with a lower cache size which gets filled completely by the working set data of the Application ? How would the Application Behave ? How would PerfAccel behave ? 

We will cover this aspect of PerfAccel i.e. Evictions in our next blog. 

In the meantime, you can go ahead and Download PerfAccel right now and get hands on with the exciting features.

Stay tuned……

Share it
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
COMMENTS SECTION

Leave a Reply

Be the First to Comment!

Leave a Reply

wpDiscuz