Optimize flash memory in Linux
I/O Scheduler Performance
The I/O schedulers, Deadline, Noop, and CFQ, are central components in the Linux block layer. You decide how and in what order the kernel passes I/O requests to the block device – the SSD in this case.
The Deadline or Noop schedulers are best suited for SSDs. The Deadline scheduler tries to guarantee a services start time for requests, thus making it impossible to drop individual requests. The Noop scheduler acts as a first-in-first-out queue, simply filing through the requests to the device. To discover which scheduler is currently set, you need to check a file in the sys
directory:
$ cat /sys/block/sda/queue/scheduler noop [deadline] cfq
Things get a little more complicated with the CFQ scheduler. The CFQ scheduler attempts to treat applications fairly in terms of I/O. CFQ is also the only scheduler with priority classes, which ionice
assigns. Priority classes can be beneficial in certain situations, for example, so a low-priority backup can then run during the daytime without impairing other applications.
The CFQ Scheduler is suitable for SSDs in principle, but it cannot keep pace with Deadline and Noop when it comes to performance and latency (Figure 2). In kernel 4.2, the CFQ scheduler was given a special SSD mode.
Reducing Write Access
Many distributions start swapping relatively quickly by default, that is, they outsource virtual memory pages from memory (RAM) to the swapspace on the hard drive or the SSD. Using the swappiness
parameter, you can manage the threshold at which the Linux kernel starts to outsource, which in turn will affect the total number of write operations:
$ cat /proc/sys/vm/swappiness 60
A high value (maximum 100) means that Linux will swap out pages belong to inactive processes earlier, which in turn translates to increased I/O activity. A lower value keeps the pages in RAM for longer and only swaps them out if the system is suffering from a lack of memory, because the other processes are using up the remaining RAM. Red Hat recommends a value of 10 for latency-sensitive database systems whose pages need to be kept in RAM [3] whenever possible. You can set this value permanently in a sysconf
file:
$ sudo vi /etc/sysctl.d/ 60-swapiness.conf vm.swappiness=10
Another technique for saving writes relies on a temporary filesystem. One characteristic of tmpfs
is that it stores its data in memory and does not write to disk or SSD.
One good example of meaningful use is saving crash dumps, which are generated by faulty programs, often in connection with segmentation faults. Admins can use the files for debugging later on; it is thus sufficient to store crash dumps to a temporary directory. This strategy avoids burdening the SSD with write operations when creating the dumps. The following commands
$ mkdir /mnt/crashdumps $ mount -t tmpfs -o size=1g tmpfs /mnt/crashdumps
set up the required redirection of the temporary filesystem.
SSD Monitoring and Smart Attributes
When you are running SSDs, the durability of the flash cells is at least as important as their performance – after all, the floating gates of the flash cells are worn out by writes. A cell has only a limited lifetime, which is expressed as the number of possible program/erase cycles (P/E cycles). Two durability indicators quantify the degree of wear:
- The Media Wearout indicator, which represents the wear of the flash cells.
- The number of remaining spare blocks, which indicates the available reserved space.
The ideal situation is for manufacturers to give users access to these indicators as smart attributes. Unfortunately, every manufacturer takes a different approach to specifying the attributes due to a lack of standardization. Table 1 illustrates the differences.
Table 1
Smart Specification
Intel | Samsung | Crucial |
|
---|---|---|---|
Smart attribute ID |
233 |
180 |
180 |
Attribute Name |
Available Reserved Space |
Unused Reserved Block Count |
Unused Reserve (Spare) NAND Blocks |
Attribute Value |
Value (in percent) |
Value (in percent) |
Raw Value, absolute number of remaining spare blocks |
Whereas the normalized value indicates the number of spare blocks in percent for Intel and Samsung, Crucial uses the raw value. You need the vendor's smart specification to correctly interpret the values.
On Linux, smartmontools
is useful for querying the values of an SSD. Manufacturers such as Intel and Samsung have also developed their own tools (isdct
, magician
) that also let users access the smart attributes.
At the command line, the smartctl
command in Listing 2 retrieves the SSD statistics (assuming the SSD provides them): In a professional environment, SSD monitoring should be integrated into a monitoring solution such as Nagious or Icinga (Figure 3).
Listing 2
smartctl
sudo smartctl -a /dev/sdb |egrep -i 'space|wear' 01 232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always - 0 02 233 Media_Wearout_Indicator 0x0032 100 100 000 Old_age Always - 0
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)