Spotlight | Reviews | Current Issue | Academy | Newsletter | Subscribe | Shop |
Departments

Partner Links
Make your own website
WinWeb OnlineOffice
Comparing prices of hardware is worth it.
Price Comparison
UK Linux Jobs
What:
Where:
Country:
vacatures Netherlands njobs Linux vacatures
arbeit Deutschland njobs Linux arbeit
work United Kingdom njobs Linux jobs
Lavoro Italia njobs Linux lavoro
Emploi France njobs Linux emploi
trabajo Espana njobs Linux trabajo

user friendly

Admin Magazine

ADMIN Network & Security

Subscribe now and save!

ADMIN - Explore the new world of system administration! Special introductory offer! Order by September 30th to save 10% off the regular subscription price! Each issue delivers technical solutions to the real-world problems you face every day. Learn the latest techniques for better:

  • network security
  • system management
  • troubleshooting
  • performance tuning
  • virtualization
  • cloud computing

 

on Windows, Linux, Solaris, and popular varieties of Unix.

http://www.admin-magazine.com/

  linux-magazine.com » Online » Blogs » Productivity Sauce » Three Simple Tweaks for Better SSD Performance  

Productivity Sauce
Productivity Sauce

Three Simple Tweaks for Better SSD Performance

As I explained in the previous post, replacing my notebook's hard disk with an SSD significantly improved the overall system performance -- even without any additional tweaking. But there are also a couple of simple tricks that can boost performance even further. The first one is to disable the sreadahead service. The sreadahead tool helps to speed up the boot process with conventional hard disks, but it actually slows the boot with SSDs. To disable the service, open the sreadahead.conf file for editing using your preferred text editor:

sudo nano /etc/init/sreadahead.conf

Comment then the following line:

exec /sbin/sreadahead -t 0

Next trick is to add the elevator=noop kernel boot parameter to disable the elevator scheduler. On Ubuntu 9.10, open the grub.cfg file for editing:

sudo nano /boot/grub/grub.cfg

Add then the elevator=noop parameter as follows:

linux     /boot/vmlinuz-2.6.31-15-generic root=UUID=b5c7bed7-58f1-4d03-88f4-15db4e367fa0 ro   quiet splash elevator=noop

This scheduler is used to read and write data from the hard disk sequentially. Since an SSD is not a conventional hard disk, disabling the elevator scheduler significantly improves the read and write performance of your SSD.

Finally, you might want to set the file system mount option to noatime. To do this, edit the /etc/fstab file, so it looks something like this:

/dev/sda1    /  ext4   noatime,errors=remount-ro   0       1

Adding the noatime option eliminates the need for the system to make writes to the file system for files which are simply being read -- or in other words, this means faster file access and less disk wear.

That's it. Now reboot your machine, and you should notice faster boot and better performance.

Comments

noatime is safe for most application

Daniel Sydnes Nov 07, 2011 8:50pm GMT

ctime, mtime, atime dates back to the foundations of Unix is available in most POSIX-compliant operating systems.

atime (access time) is updated whenever a file system object is read -- even from cache.

ctime (ionode modification time) gets updated whenever the file system object's ionode is changed (e.g., file/directory is created, ownership is changed, permissions are changed, file/directory is deleted).

mtime (object modification time) gets updated whenever the file system object is modified (e.g., truncated, appended, overwritten).

Well-written backup applications use the mtime to flag modified files for progressive, incremental, and differential backup modes. If the backup application also preserves ownership & permissions, it should also look at ctime. atime is no use whatsoever here -- backups are interested about file changes -- not reads.

atime has a few edge cases. Some systems audit file reads to track usage. tmpwatch removes aged files from the /tmp directory based on atime. mail-notify looks at atime to notify users about new mail. Cache & proxy servers once used atime for pruning objects from their cache, but this has been largely replaced by tree indices that can weigh multiple factors (e.g., number of requests vs. aging).

For the most part noatime is completely irrelevant. If in doubt, read the opinions of the holy trinity of Linux development -- Linus Torvalds, Andrew Morton, and Ingo Molnar:
http://kerneltrap.org/node/14148

noatime may break some applications like backup tools

alp Nov 27, 2009 3:52pm GMT

If you are using Karmic, relatime will be safer bet. Note that this option might not work well with older kernels.

noatime implies nodiratime

anon@example.com Nov 26, 2009 4:37pm GMT

A common confusion - http://lwn.net/Articles/245002/ .

Anon

anon@example.com Nov 26, 2009 4:35pm GMT

Disabling readahead may not be a win (at boot) as it will fetch blocks earlier than they would have been fetched otherwise and (depending on the readahead implementation) only when disk I/O would otherwise be idle. Thus more is done I/O is done in parallel earlier in the boot process so programs wait even less leading to a faster boot reagardless of the fact the underlying disk does not have a read seek penalty...

Something similar may apply to general readahead too - if you are going to need those blocks later sequential readahead can still be a win as you will simply wait less later (at a point when you would have had to stall).

sreadahead

max stirner Nov 26, 2009 2:49pm GMT

note that karmic doesn't use sreadahead, it uses ureadahead which automatically detects ssds and performs appropriately.

journaling on SSD is also a bad idea

gus3 Nov 26, 2009 2:36pm GMT

By doubling the number of writes in certain operations, it increases the wear on the SSD, and slows things down even more. Ext2 may be old (and well-debugged), but it is still a strong contender for certain workloads. Until btrfs reaches production quality, ext2 is probably the best way to go for SSD.

fstab

Fred Silva Nov 26, 2009 2:19pm GMT

One more tip, add "nodiratime":

/dev/sda1 / ext4 noatime,nodiratime,errors=remount-ro 0 1

setting readahead values for just one drive

Matt@faktura Nov 26, 2009 11:23am GMT

If you want to set the readahead for just one device you can adjust it using the blockdev command like so;

blockdev --setra 0 /dev/sda

Obviously you'll want to put this command in a init.d file or similar...

p.s. this is only for 2.6 kernels

Test results

Lumpy2000 Nov 26, 2009 11:13am GMT

It would be very interesting to see speed results. how big performance increase exactly we will get form this tune up?

Re: GRUB configuration changes

Dmitri Popov Nov 26, 2009 9:08am GMT

@Juergen Pabel: gus3 has already mentioned this technique, but thanks a lot anyway!

Re: Quality information

Dmitri Popov Nov 26, 2009 9:06am GMT

@Andrea R: Actually, I wrote both posts on the same day, so the fact that you mentioned the tweaks covered in the article is just a coincidence. Or maybe not, since all the tweaks are more or less well-known.

There are many ways to skin a cat, and I don't pretend that my way is the best one. However, I did try all the modifications myself and they worked.

You are right, though. I should have thanked you for commenting on my post. I'm always grateful to people who find time to share their ideas and knowledge with others. Thank you!

GRUB configuration changes

Juergen Pabel Nov 26, 2009 9:01am GMT

Hi,

on Ubuntu 9.10 I recommend editing /etc/default/grub instead of /boot/grub/grub.cfg. Any changes made to /boot/grub/grub.cfg directly will be lost the next time update-grub2 is executed (like when a new kernel or kernel-patch is installed via software update). So, by changing the line

GRUB_CMDLINE_LINUX_DEFAULT=quiet splash"

to

GRUB_CMDLINE_LINUX_DEFAULT=quiet splash elevator=0"

in /etc/default/grub and then running update-grub2 one can make this change more persistent.

Juergen Pabel

Re: editing grub.cfg is not advised in Ubuntu

Dmitri Popov Nov 26, 2009 9:00am GMT

@gus3: You are absolutely right. Thanks for the tip!

thanks

Michael Creel Nov 26, 2009 8:31am GMT

Thanks for the hints, and thanks to the people who commented on them. I notice an improvement.

Quality information

Andrea R Nov 26, 2009 2:44am GMT

Hilarious, you basically took my comment to a previous entry and made it into a whole new post. You forgot the filesystem suggestion and put the noatime trick instead, which is not ssd-specific.

You also do things in a terribly dirty way.
Learn to disable a service. Uh uninstall readahead may be even esier. That and editing grub configuration properly.

Why don't you give it some time, get some real experience and test the modifications thoroughly then start filling the web with quality information?
Also, next time at least say "thank you".

editing grub.cfg is not advised in Ubuntu

gus3 Nov 26, 2009 2:27am GMT

Any edits to /boot/grub/grub.cfg will probably be lost at the next kernel upgrade.

The preferred way to change boot parameters in Ubuntu 9.10 is by editing /etc/default/grub, altering the line that starts with GRUB_CMDLINE_LINUX_DEFAULT=... to suit your needs. Once you have saved it, run update-grub to apply the changes to /boot/grub/grub.cfg. Verify that the changes are in place, and then reboot.

Or, in the specific case in this article, just "echo noop > /sys/block/DEVICE/queue/scheduler" to change the elevator without rebooting, substituting the correct device name for DEVICE.

Print this page. Recommend
Share