Solid-state disks (SSD) use NAND flash chips rather than rotating magnetic platters to store persistent data. They provide a constant access time for data across their full Logical Block Address range, and do not incur measurable seek costs like their rotating counterparts. They are more expensive per gigabyte of storage space and have a lesser storage density, but they also have lower latency and greater throughput than HDDs.
Performance generally degrades as the used blocks on an SSD approach the capacity of the disk. The degree of degradation varies by vendor, but all devices experience degradation in this circumstance. Enabling discard behavior can help to alleviate this degradation. For details, see Section 220.127.116.11, “Maintenance”
The default I/O scheduler and virtual memory options are suitable for use with SSDs.
SSD Tuning Considerations
Consider the following factors when configuring settings that can affect SSD performance:
Any I/O scheduler is expected to perform well with most SSDs. However, as with any other storage type, Red Hat recommends benchmarking to determine the optimal configuration for a given workload. When using SSDs, Red Hat advises changing the I/O scheduler only for benchmarking particular workloads. For instructions on how to switch between I/O schedulers, see the
As of Red Hat Enterprise Linuxnbsp 7.0, the default I/O scheduler is Deadline, except for use with SATA drives, which use CFQ as the default I/O scheduler. For faster storage, Deadline can outperform CFQ leading to better I/O performance without the need for specific tuning. Sometimes, the default is not suitable for certain disks, such as SAS rotational disks. In such cases, change the I/O scheduler to CFQ.
Like the I/O scheduler, virtual memory (VM) subsystem requires no special tuning. Given the fast nature of I/O on SSD, try turning down the
vm_dirty_ratio settings, as increased write-out activity does not usually have a negative impact on the latency of other operations on the disk. However, this tuning can generate more overall I/O, and is therefore not generally recommended without workload-specific testing.
An SSD can also be used as a swap device, and is likely to produce good page-out and page-in performance.