VeloBit Blog on SSD, Application Performance and Storage

Effect of Block Sizes and Outstanding IO Requests on SSD performance - Intel X25-V

This blog continues the a series which present test results of extensive testing performed at Velobit to investigate SSD IO bandwidth when SSDs are operated in a simulated enterprise environment.  The test set up and procedure is documented in the first blog post of this series which can be found by clicking here.

Test SSD: Intel X25-V SATA based SSD


Figure 1: IO Bandwidth for Intel X25-V Drive: a) random read b) sequential read


Figure 2: IO Bandwidth for Intel X25-V  Drive: a) random write b) sequential write

Figures 1 and 2 shows the results for the Intel X25-V SSD. For both random read and random write requests, the request size determines the maximal performance.  The interesting result for this drive is that the maximum write performance is achieved even for very small request sizes for both random and sequential write requests.

Come back next week for results and observations on another SSD.

Effect of Block Sizes and Outstanding IO Requests on SSD performance -Samsung 470 250 GB

This blog continues the a series which present test results of extensive testing performed at Velobit to investigate SSD IO bandwidth when SSDs are operated in a simulated enterprise environment.  The test set up and procedure is documented in the first blog post of this series which can be found by clicking here.

Test SSD: Samsung 470 Series 250 GB SATA based SSD

Figure 1: IO Bandwidth for Samsung 470 Drive: a) random read b) sequential read


Figure 2: IO Bandwidth for Samsung 470 Drive: a) random write b) sequential write

Figures 1 and 2 shows the results for the Samsung 470 Drive. Like the previous results, the request size determines the performance instead of number of outstanding IO. This device handles random requests very well. We can see that the random read and random write perform almost the same compared with their sequential counterpart, even when the request size is small, e.g., 1 KB.
 
Come back next week for results and observations on another SSD.

Effect of Block Sizes and Outstanding IO Requests on SSD performance

This blog begins a series of blogs which present test results of testing performed at Velobit to investigate the effect of block sizes and outstanding IO requests on IO bandwidth when SSDs are operated in a simulated enterprise environment. This series of blogs is similar to the series we previously presented documenting IO bandwidth vs. read/write ratio. This first blog will document the test set up and procedures and present the results from one tested device. In following weeks, I will refer the reader back to this blog for test set up and procedure information and simply present the results for another device. After presenting results of a particular week, I will make observations as appropriate.

Test Motivation and Procedure
For this group of tests, we wanted to focus on the effect of the number of outstanding IOs and request size on SSD IO bandwidth.  We are particularly interested in observing the impact of increasing the number of concurrent IOs and request size.  We want to see which of the factors has the biggest effect on IO bandwidth and which workload type. Because of the internal parallel structure of SSD we anticipate that there should be performance benefits from sending multiple requests to the SSD.  SSDs should be able to serve multiple small random or sequential requests simultaneously.  SSDs also can break big sequential requests into small requests to take advantage of their internal RAID-like structure.
 
We tested 8 different SSDs from 6 different manufactures. Some are SATA devices and some are PCI-E devices. We used a Linux based system running with the Intel Open Storage Toolkit, a tool similar to Iometer that runs on Linux. The Open Storage Toolkit generates synthesized workloads with various sizes and queue lengths and also provides monitoring and IO tracing capabilities. We also used another set of tools available in Linux, blktrace and blkparse that intercept all block-level requests. The idea was to observe IO bandwidth under operating conditions.

So for this test, we ran an identical test suite for each SSD and observed IO bandwidth. We used 6 different IO request sizes: 1 KB, 4 KB, 16 KB, 64 KB, 128 KB and 256 KB and varied the outstanding IO requests from 0 to 64. We ran 4 different sets of these tests based on IO type: random read, sequential read, random write and sequential write.

General Observations
In general, we observed that the largest IO request sizes generally provided the maximum IO bandwidth.   Increasing the number of outstanding IO requests did increase IO bandwidth.  In many cases a relatively small amount of outstanding IO requests would allow the SSD reach the maximum bandwidth for any particular request size.

Test SSD: 250 GB OCZ Z Drive PCI-E based SSD

Figure 1: IO Bandwidth for OCZ Z Drive: a) random read b) sequential read


Figure 2: IO Bandwidth for OCZ Z Drive: a) random write b) sequential write

Figures 1 and 2 shows the results for the OCZ Z Drive.  For all the four workload types, the bandwidth increases as the number of outstanding IO increases, which indicates that there is a significant amount of parallelism within the device.  However,  the benefit of increasing the number of outstanding IO is highly dependent on the request size.  When the request size is 1 KB or 4 KB, the benefit of increasing the number of outstanding IO is very limited.   When the request size is 16 KB, 64 KB, 128 KB and 256 KB, the performance increases very quickly with just a small increase in the number of outstanding IOs.

It appears that the OCZ Z drive is quite sensitive to the number of outstanding IO for some test cases. For random read workloads, the SSD performance continues to increase even when the number of outstanding IOs is more than 32.  This indicates that the high end PCI-E based OCZ Z drive can process as many concurrent requests before reaching its performance limit.

Come back next week for results and observations on another SSD.

What’s In A Name? Linux Really Cares

The IT Dog here barking about Linux and what can happen if you are not careful with how you manage device naming.  I’m talking about all kinds of hardware Linux sees in your system when it boots up – disk drive partitions, SSDs and even USB and camera devices.  If device naming is not done correctly, problems can occur when device names are changed during a Linux reboot, causing all kinds of application problems.

Taking Things One Device At A Time
Linux likes to do things simply and efficiently.  The Linux kernel has the ability during startup to identify hardware devices and assign names to them based on device type and quantity.  Linux assigns a unique name to each found devices.  The problem occurs when a device is removed or relocated within the system.  On reboot, the Linux kernel may identify the devices in a different order and the previously assigned name for the device can change.  This can cause all kinds of application data access problems as you might imagine.

Older versions of the Linux kernel contained static device files which produced large files with sometimes obsolete information.  The solution to that was to have Linux  dynamically identify devices and assign them unique names.  While this solved the large, obsolete file problem, a new problem developed - the name reassignment problem.  A simple example of this would be if you had two disks that were originally defined as disk A and disk B and for some reason these two disks were physically swapped, the next time Linux rebooted, Linux would assign the name ‘disk C’ to disk B and ‘disk D’ to disk A.  This would lead to problems with the applications looking for disk A and B for their previous data.

udev To The Rescue
The good people in the world of Linux development recognized the need to solve the name reassignment problem and developed a new device manager for Linux – udev.  “Nice name Dog, but what’s so great about udev?”  udev supports “persistent device naming” and therefore avoids the renaming of devices on each reboot.  It also avoids naming the devices in the order they are detected in the system. Any device can be defined by a unique filesystem ID, disk name and the physical location of the hardware. Once a device and name are paired, they remain paired even if the device is moved or when the system reboots.

And Now A Messge From Our Sponsor
So what does udev and device naming have to do with Velobit?  Well, the Velobit HyperCache SSD caching software uses udev to assign unique, permanent names to identify both the HDD(s) to be cached (target disk) and the SSD(s) to use for caching in the system.  That way if the system is rebooted or the HDDs and SSDs are moved, the user does not have to worry about reconfiguring the Hypercache software.  The devices are known and their identity does not change.  One less thing for you to worry about.  You can go ahead and hit that Staples “Easy” button you have on your desk now.

Effects Of Linux IO Scheduler On Intel X25-V SSD Performance

This blog is the second in a series which present test results of testing performed at Velobit to investigate the effects of the Linux IO scheduler on SSD performance when SSDs are operated in a simulated enterprise environment.  The test set up and procedure is documented in the first blog post of this series which can be found by clicking here.

Test SSD: Intel X25-V SATA based SSD

Figure 1: IO Scheduler Bandwidth for Intel X25 Drive: a) random read b) sequential read


Figure 2: IO Scheduler Bandwidth for Intel X25 Drive: a) random write b) sequential write

Figures 1 and 2 shows the results of Intel X25-V Drive. Relative to the OCZ drive presented in the last blog, the Intel X25-V drive performance is not dependent on the Linux scheduler algorithm.  It appears that the internal SSD controller within the X25 drive dictates the performance of the device as postulated in the introductory blog on this topic.  Since the Linux schedulers were developed for HDDs it was anticipated that they may have no impact on SSD performance and for this device that is true.

Come back next week for results and observations on another SSD.

Techniques Used To Reduce Writes To SSDs

SSDs are being used in many applications in IT systems for both caching and primary storage. Regardless of what SSDs are being used for, how they are used matters greatly. Because of the characteristics of the NAND-based flash devices in SSD, writing data to SSDs must be carefully managed.

SSD Write Concerns
SSD are primarily made from NAND-based flash memory devices which are organized using fix-sized memory sections called ‘pages’ (typically 2KB or 4KB in size). A fixed number of these pages compose a flash ‘block’ (512KB for example). Prior to writing a data page into an SSD block, the complete block in the NAND flash device must be erased. If active data was contained in the block prior to erasure, that data must be moved to a new block. This process of moving active data from one block to another simply to write in a new page of data is called garbage collection and the fact that writing to the SSD triggers additional internal writes is called write amplification. Write amplification is a major concern when deciding to write data into an SSD.  To further complicate matters, NAND flash devices have a limited amount of write/erase cycles that can occur before the NAND device wears out and becomes inoperable.

Multiple Ways To Reduce Writes To SSDs
The issues discussed above regarding writing to SSDs are well known and much research has been done to both improve flash devices and reduce the amount of data written to SSDs. Here are some techniques currently being used to reduce SSD data writes:

• Application layer: Applications can be developed to specifically address the SSD write concern by simply minimizing write to the SSDs. In this case, an application can consolidate writes (sometimes called write coalescing) and reduce write amplification.
• Data Deduplication: Data deduplication is a data reduction technique that simply removes duplicate data from the data stream. This means that it only removes data that is exactly like a block (or “chunk”) of data previously stored.  This reduces the amount of data written into an SSD.
• Data Compression: Data compression is a technique where the original data is encoded into another representation of the data. The subsequent encoded version of the data uses less bits to represent the original data (e.g. music mp3 files). There are many forms of data compression. Some retain all of the original data exactly (lossless compression) and some (like mp3) do not retain all of the original data but exhibit some loss in the data representation (lossy compression). In either case, the goal is to reduce the size of the data set being written into SSD.
• Collect statistics:  Algorithms can be run to monitor data blocks to classify blocks by groups based on write frequency. Once information is collected on the write characteristics of the data, the algorithm can combine blocks with similar write frequency together. When the time comes to erase a block, chances are that entire block is obsolete at the same time so no valid data is required to be moved to a new block. In this case, garbage collection and hence write amplification are decreased.
• Use SSD as cache: Using SSD as cache allows caching algorithms to be used to analyze and select data to be written into cache. Cold data can be identified before it is ever written into the SSD, thereby eliminating unnecessary SSD writes.

Conclusion
No matter how you use SSDs in your IT system, be sure to understand the implications of excessive writing to the SSD and design or use software that effectively manages the SSD to reduce write amplification and premature wearing of the device.

Effects Of Linux IO Scheduler On SSD Performance

This blog begins a series of blogs which present test results of testing performed at VeloBit to investigate the effects of different Linux IO scheduler algorithms on IO bandwidth when SSDs are operated in a simulated enterprise environment. This series of blogs is similar to the series we previously presented documenting IO bandwidth vs. read/write ratio. This first blog will document the test set up and procedures and present the results from one tested device. In following weeks, I will refer the reader back to this blog for test set up and procedure information and simply present the results for another device. After presenting results of a particular week, I will make observations as appropriate.

Test Motivation and Procedure
For this group of tests, we wanted to focus on the effect of the selected Linux IO scheduler on the IO bandwidth performance of the SSD. An IO scheduler controls the way the Linux kernel commits reads and writes to disk (or SSD). There are several different schedulers supported by Linux; each one having particular advantages with respect to particular IO workload. The Linux kernel supports 4 different IO schedulers:

• No-op scheduler (NOOP)
• Complete fair queueing scheduler (cfq)
• Deadline scheduler
• Anticipatory scheduler

However, these schedulers are designed for HDD.  For SSD installations, an IO scheduler may not be required since each SSD has its own specific scheduler inside the SSD controller.

We tested 5 different SSDs from 4 different manufactures. Some are SATA devices and some are PCI-E devices. We used a Linux based system running with the Intel Open Storage Toolkit, a tool similar to Iometer that runs on Linux. The Open Storage Toolkit generates synthesized workloads with various sizes and queue lengths and also provides monitoring and IO tracing capabilities. We also used another set of tools available in Linux, blktrace and blkparse that intercept all block-level requests. The idea was to observe IO bandwidth under operating conditions.

So for this test, we ran identical test suite for each IO scheduler algorithm listed above and observed IO bandwidth. We used 6 different IO request sizes for each scheduler: 1 KB, 4 KB, 16 KB, 64 KB, 128 KB and 256 KB. We ran 4 different sets of these tests based on IO type: random read, sequential read, random write and sequential write.

General Observations
Overall, for the 5 devices tested, we found that none are very sensitive to different IO scheduler algorithms and no consistent results were observed across all devices. However, there are some interesting observations to be made. The NOOP scheduler is generally believed to be the best used with SSDs because SSDs do not depend on mechanical movement to access data. Such non-mechanical devices do not require re-ordering of multiple I/O requests (grouping together I/O requests that are physically close together on the disk), thereby reducing average seek time and the variability of I/O service time. These test results show that the NOOP scheduler is not necessarily the best for all devices.


Test SSD: 250 GB OCZ Z Drive PCI-E based SSD

Figure 1: IO Scheduler Bandwidth for OCZ Z Drive: a) random read b) sequential read


Figure 2: IO Scheduler Bandwidth for OCZ Z Drive: a) random write b) sequential write

Figures 1 and 2 shows the results of OCZ Z Drive. Relative to the other schedulers, the anticipatory scheduler performs poorly for the random read workload.  The reason is that this scheduler tries to avoid disk seek operations by waiting a very short time for another read that is physically located near the current read request. This introduces some overhead for SSD because even a short waiting time for SSD is not necessary. The same anticipatory scheduler does not affect write performance because it only executes the “wait” during read requests. For sequential read, the anticipatory scheduler also does not have any negative effect because the next read request it is waiting for is physically close to the current read request, so its performance is similar to the other three schedulers.

Also note that for random workloads (both read and write), the NOOP scheduler performs the worst when the request size is big (128 KB and 256 KB). This is because NOOP puts all requests into a simple FIFO queue, which means that requests must be processed in order and new requests cannot be processed unit one is completed.  This is different than schedulers which are multi-queue (complete fair queueing , deadline or anticipatory).  These schedulers can process requests in parallel.

Come back next week for results and observations on another SSD.

Is Your Data On “The Highway To Hell”?

Please forgive the IT Dog  for channeling a little AC/DC today.  I needed some way to get ‘highway’ and ‘data’ in the same sentence and you’ll see in a minute why ‘Highway to Hell’ is appropriate here.

I was reading a blog on the Nevex website regarding block-based vs. file-based caching and the author started using a “highway full of cars” as an analogy for moving data around.  So, I decided to run with this highway imagery and explain how doing file-based caching is like putting your data on the 405 freeway at LAX, 5 pm on a Friday before Labor Day weekend – i.e. a “Highway to Hell.”

File-Based Caching?
Velobit recently posted a blog which discussed the many locations SSD caching software can be installed.  I am stealing the diagram from that blog post just to show where file-based caching lives.  It is labeled as location ‘4’ in the diagram below.


And as was discussed in the blog post, implementing SSD caching software at the file system level is easy to develop, easy to install but has limited performance.  By sitting above, or inside, the file system, a user can specify precisely which files (and by association, applications) to cache.  This solution is very dependent on the OS file system and is difficult to support something like Linux which has many different file systems.

Just for reference, Velobit HyperCache SSD caching software is deployed in location 2 in the figure and operates at the block level.

“What About The Highway, Dog?”
I’m getting to that…  The Nevex blog talks about file-based caching by saying this: “Imagine watching a highway full of cars and knowing who the driver is in each car, where they came from, why they are on the highway, whether or not they’re in a hurry, and which other cars are going in the same direction. What that means is that with file-based caching one can focus the increased performance where it matters (the special lanes for selected traffic) instead of building a bigger highway for everyone.”

So the file-based solution for caching is to build a special lane for selected traffic.  To decide what cars (data) go in the special lane, they need to know who the drivers are and where they are going, etc.  They don’t seem to care how many passengers are in each car (the basic idea of a HOV lane on a real highway, by the way).

Let’s continue the “highway” analogy and discuss three “economic efficiencies” used in the Nevex blog that they say most customers are concerned with: performance value, resource efficiency, and management cost.

Performance Value: If you base caching decisions only on the criteria of knowing who the driver is and where they are going and who is in a hurry, you may end up with a traffic jam in the fast lane with all those IMPORTANT cars with one passenger each!

Resource Efficiency: Imagine a special lane full of important, high priority cars with only the driver in each car.  This makes me think of high overhead for low volume throughput the complete opposite of resource efficiency.   Maybe we should look at how many people are in each car (e.g. AC/DC heading to the Wembley Stadium) and decide if they get to use the limited resource of the ‘fast lane.’

Management cost: Let’s see, to get the file-based caching solution right I need to know exactly who the driver is, where they are going, where they came from, why they are on highway, whether they are in a hurry, and which other cars are going in the same direction.  That’s it?? How is looking for all that information less costly than simply looking at number of people in each car as they go by?

Sound Like The Highway To Hell Yet?
So the highway with the special lane for special traffic may be great for special situations but it hardly seems like a good solution for a dynamic data environment.  Creating a static, predetermined solution like the file-based system cannot outperform a dynamic block-based solution in a changing environment.  And, I would like to be in the meeting where the IT guy tells one group of applications guys that their application is not important enough to get access to the special lane on the highway.  “Who is making the money at this company? Us or the IT manager?” the apps guys are yelling….They have to yell to be heard over the noise of the Highway To Hell!

The VeloBit Launch: Looking Back, Looking Forward

The release of VeloBit HyperCache v1.1 is a major milestone and celebration for VeloBit and our customers, partners and investors. I’m pleased with the response we’ve received, and especially proud of our team. I like to pause and reflect at major milestones. This blog shares my reflections on the last year and a preview of what you can expect from VeloBit in the next year.

Looking Back

Nine months ago I wrote a blog on why I joined VeloBit, outlining our market opportunity and why I thought VeloBit would be successful. I couldn’t be happier with how things have played out since then. Back in August, we predicted the emergence of SSD Caching Software as an important category (though no one called it “SSD Caching Software”, since our category was unnamed). Customers told us that the cost of SSD and complexity of existing SSD deployment models were constraining adoption in the enterprise. We expected that solutions to these two problems would get a strong market reception.  

VeloBit’s plan was to leverage our patent-pending inventions (content locality caching, line-speed data compression, horizontal architecture, etc.) to build a caching solution that would deliver large advantages in performance, cost, and ease of deployment. We set out to build a plug & play solution that could be deployed in 10 minutes, and that would sit invisibly between an application and its primary storage – allowing customers to gain the benefits of SSD while preserving their existing storage systems and processes.  

In addition to product innovation, we set out to introduce a low-cost, download-driven distribution model to the storage market - and pass our sales & marketing cost savings on to our customers and partners.

VeloBit Today

Our market has emerged much faster than any of us could have dreamed. The feedback we got from our early customer conversations has been verified and amplified. The enterprise SSD market craves lower costs and easier deployment, and SSD caching is the best path to achieve these. EMC’s introduction of VFCache validates the importance of SSD Caching (and gives VeloBit an easy comparison for our performance, cost and ease of use). Most of the storage analysts cover SSD Caching Software, and Wall Street analysts include “SSD Caching” in their research reports. 

Through some combination of luck and foresight VeloBit has caught a huge wave. SSD caching software is emerging rapidly, and VeloBit is a leader.  

It’s not enough to pick a good market. A company needs to execute, and I couldn’t be prouder of team VeloBit. Prakash Manden (VP Engineering) and Qing Yang (CTO) and the engineering team they lead have done a terrific job delivering exceptionally innovative products. VeloBit is the world’s fastest, most cost-effective, and easiest to install SSD cache. Later this week we’ll publish 3^rd party benchmarks that will blow people away! Our list of inventions is long and growing – with innovations in content locality caching, line-speed data compression, sequential scan filtering, inter-server cache coherence, and others. We recently received our first issued patent, and have another half dozen patents filed. VeloBit has the technical lead, and our lead is growing. Significantly, our engineering team has crushed our “ease of installation” goals. We targeted a 10-minute installation. VeloBit v1.1 installs in 60 seconds!  

Customers such as Masergy, Zoom Info, and DataFeedFile.com are seeing the benefits of VeloBit, speeding queries up to 20x (Masergy), boosting application throughput by 4x (Zoom Info), and cutting power and costs. They’re achieving these results without spending on high-end PCIe drives. VeloBit today drives strong acceleration at low cost for a broad set of applications including database/data warehouse (MySQL, SQL Server, Oracle, PosgreSQL, Cassandara), virtualized environments, financial analysis and simulation, enterprise search, e-commerce, web applications, and Hadoop. The list of applications is long and growing. Of particular note is our addition this month of a fast and inexpensive solution for VMware acceleration.

In the last 9 months, we have built a marketing and sales organization as well. Peter Velikin joined as head of marketing in September and has put VeloBit on the map. Our collection of blogs, white papers, deployment guides and webinars has become a must-read resource for customers planning their SSD deployments. Nearly 10,000 visitors came to VeloBit.com in April to peruse our content, generating over 200 leads. Both numbers are growing rapidly.

In March, Mike LaPeters joined as VP Sales to help drive our low-cost sales model. Through the combined efforts of Mike and Peter, together with a plug & play product that is drop-dead easy to install, VeloBit’s download driven sales model is taking off. Today we have 35 installations across 5 continents and are adding new installations at a rapid clip.  

There have been positive surprises in our distribution model as well. We have received much more inbound interest from value added resellers and OEM’s than we could have expected. In response, we’ve introduced a reseller program. We’ll have a double-digit number of VeloBit-certified VARs, across the globe, by the end of the month. Watch for OEM announcements soon as well.

Looking Forward

Over the last 9 months, we’ve identified additional customer needs. The first is a strong desire for hardware-agnostic SSD caching software. Customers hope to avoid vendor lock-in with the caching software. Great news for VeloBit! With the acquisition of our primary competitors, VeloBit now stands as one of the only hardware-neutral solutions in the market.

Additionally, we have seen strong demand for VeloBit on all major OS platforms. We raised more capital in February to speed development – and have added VeloBit for VMware, Windows, and Hyper-V to our release schedule. We will support all these major platforms by June.  

Finally, as enterprise SSD makes its way into important applications, customers have started to ask for hardened write-caching solutions that provide higher-availability and support clustered environments. Watch for some announcements from us later this year on this front.  Qing and the team have yet more clever innovations coming down the pipe.

VeloBit is growing rapidly. We move to our new offices in Lincoln later this month to accommodate all the great new people we are adding to the team.

On a final note, I’d like you all to know that VeloBit is hiring. Please visit www.velobit.com/careers for opportunities to help us drive our rapid growth.

May all your applications run faster and cheaper,

Duncan McCallum

CEO & Cofounder, VeloBit

Using RAM in SSD Caching

Dr Dog  Says “You Need More RAM In Your Cache Diet”

Well, I am not really a doctor, but I play one on TV.  You may remember (if you are old enough) that line from the 1986 Vicks-44 TV commercial.  Anyway, while I may not be a real doctor, I can certainly tell you about why you need more RAM in you cache diet.

“I Think My Cache Diet Is Great”

If you were happily running your IT system but needed some additional performance, chances are you turned to some kind of SSD caching solution to improve performance at a lower cost point than adding more servers or storage.  You went on what I am calling a “cache diet” (no, not the “crash diet” you went on last year to lose a few lbs).  You may think your cache diet is great.  “Dog, we got some performance improvement and the applications guys are not bothering me anymore, at least for now.”  And it is true, you did see some performance improvement when you went to an SSD caching solution….but now, things are starting to slow down again and the applications guys are making noise again.  You are experiencing IO bottlenecks and higher latency times for data access or you just never really got all the improvements you expected. “So what do I do now, Dr. Dog?”  Well, the problem is the SSD cache solution you implemented does not have any RAM in it and the solution from the good doctor is “you need more RAM in your cache diet.”

We Call It “Hybrid Caching”

SSD caching is a combination of an SSD device and SSD caching software.  It is being sold by many vendors and comes in many flavors.   It can be installed in many different locations in the computer system storage architecture.  This was discussed in a recently posted blogwhere the pros/cons of each location were discussed.  What was not talked about in that blog, however, was what types of caching algorithms actually used RAM as part of their solution.  At Velobit, we use a combination of SSD and RAM to implement our SSD caching software; a solution we refer to as “hybrid caching.”

“So What Does More RAM In My Cache Diet Actually Do?”

“Doctor” Dog shall explain: Using RAM with SSD cache hardware makes the life of the SSD better.  Even a small amount of RAM is effective in reducing IO loads on the SSD.  Obviously, if RAM is used for cache, a RAM cache hit is going to respond faster than any SSD and frees the SSD to perform other essential tasks such as garbage collection and complete pending writes.  SSDs perform poorly with mixed read/write IOs. A RAM cache helps limit mixed writes/reads, improving SSD performance and overall cache performance.

Velobit HyperCache SSD caching software uses RAM efficiently so even a small amount of RAM allocated to caching can impact performance.  Velobit uses compression algorithms based on content locality caching to reduce the amount of physical data stored in RAM.  The impact of this is to effectively increase the virtual cache size without dedicating excessive RAM resources to cache. And, while some file system caching software can use RAM to improve performance, those techniques do not use data compression to maximize the performance of the allocated RAM.

Finally, using RAM in the caching algorithm allows the Velobit SSD caching software to do selective SSD writes – it does not write data to the SSD unless the data needs to go there.  Sequential data is written directly to HDD, completely bypassing the SSD.

“I Feel Better Already”

So, if your SSD caching system seems a little, shall we say, constipated, you can probably fix that by adding a little RAM to your SSD cache diet.