Performance Over Time
According to the slide above, which we took from this year's Flash Memory Summit in Santa Clara, there are a handful of assumptions made about enterprise environments as they relate to desktops. Enterprise drives are available 24x7, they need to be evaluated after hitting steady-state performance, no down-time is accepted, and the consequences of a failure are catastrophic.
When a drive is getting hit all day, every day, and it's operating at its steady-state point, performance needs to be both acceptable and predictable. If a server's workload is running for an extended period, it won't sit idle long enough for background garbage collection to move scattered pages into single blocks, restoring performance and reducing write amplification. Naturally, that's bad if the drive is unable to cope.
Clean Performance
Examining how a drive might perform over time isn't that difficult. First, we just have to fill up all user-accessible space using a sequential write, making the drive "dirty." Then, we subject it to a 4 KB random write with a queue depth of 32. Because the drive is full of data, though, garbage collection can't consolidate scattered pages into free blocks. When we start writing sequential data again, the effects of active garbage collection kick in.
Random Writes, 20 Min.
If the drive recovers quickly, you can be fairly certain that there's lots of active garbage collection going on.
When we subject the SSD 710 to 20 minutes of torturous random writes, we start to see small differences. Whereas the 320 employs foreground garbage collection over an extended period, the 710 has a tendency to perform a lot of garbage collection all at once. As a result, we only see one dip in performance, recovered from relatively quickly.
That's not the only difference, though. When you look at the 320's chart, it's apparent that some garbage collection even occurs during read operations. We get confirmation when we revisit the endurance test. After running the database profile for six hours, we see a higher write amplification value.
The SSD 710 doesn't do any garbage collection on reads, but its write amplification goes down as a result of the 40% over-provisioning, which decreases the amount of data rearrangement necessary to optimize performance.
| Endurance Calculations (Workload Counters) | Intel SSD 710200 GB | Intel SSD 320 300 GB |
|---|---|---|
| 4 KB 100% Random WriteQD= 32, 6 Hours | WA = 5.091437 TBW | WA = 2.75132 TBW |
| Database 67% Random ReadsQD =32, 6 Hours | WA = 4.031818 TBW | WA = 3.49104 TBW |
Perhaps all of those pretty pictures depicting performance up in the 100 MB/s range paint an overly optimistic picture of performance, though. Hammering the SSD 320 with 4 KB writes for 20 minutes still represents a fairly desktop-oriented workload. If we sustain that workload for hours, as you might see in an enterprise, random writes fall to as low as 20 MB/s. When we subject Intel's SSD 710 to an hour of random writes, its advantage over the desktop-oriented hardware becomes more clear.
Random Writes, 60 Min.
According to Iometer, sequential read/write performance should be in the 175-200 MB/s range. Performance drops precipitously, though, as very little garbage collection occurs in real-time.
If we combine these results with our endurance test, we see that the 710 handles foreground garbage collection more adeptly, thanks in part to the large amount of over-provisioning. As a whole, this contributes to a minimum sequential write speed of 60 MB/s. In comparison, the 320 relies more on background garbage collection (particularly during reads) in order to recover performance.
After 30 Min. Idle
In either case, if you give the drives some idle time, performance recovers to a clean state, even without TRIM.
