[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSD optimization on Debian (2014)



KS wrote:
> I have done the following for optimization (ref:
> https://wiki.debian.org/SSDOptimization?action=show&redirect=SSDoptimization):

I wanted to say that I think that page needs an update for Wheezy.  At
one time there were many things needed for SSDs.  The biggest being
alignment to 4k Advanced Format partitions.  But if installing Wheezy
Stable then I think the entirety of that page can be ignored.

> 1) Kernel: Linux localhost 3.14-1-amd64 #1 SMP Debian 3.14.9-1
> (2014-06-30) x86_64 GNU/Linux

Good to go.  But so is the default 3.2 Wheezy kernel too.  Either is
fine.  My main laptop is still running the 2.6.32 Squeeze kernel on an
SSD.

> 2) Updated the firmware for the Intel 530  240GB disk

Sure.

> 3) I have not gone into partition alignment for two reasons: 1) the
> article on debian wiki refers to is from a long time ago, 2) blockdev
> doesn't indicate misalignment (see below):
> $> sudo blockdev --getalignoff /dev/sda1
> 0
> $> sudo blockdev --getalignoff /dev/sda2
> 0
> $> sudo blockdev --getalignoff /dev/sda5
> 0

If you installed Wheezy then the default installer would do the Right
Thing with respect to partitions by default.  There isn't a need to do
anything.  (Now if you were to go back and try to install Woody or
Sarge or Lenny or ... that would not be true.  But Wheezy is fine.)

> 4) For mounting file systems, I have added discard in /etc/fstab and
> also enabled issue_discards in lvm.conf

Sure.  I personally have not gone to this trouble.

The wiki does say this:

  * The "discard" options is not needed if your SSD has enough
    overprovisioning (spare space) or you leave (unpartitioned) free
    space on the SSD.
    See http://www.spinics.net/lists/raid/msg40866.html

The referenced thread has much good information concerning trim (aka
the discard option) and I recommend reading through the entire thread.
You are fine with trim enabled.  In some cases using trim may help.
In some cases using trim may hurt.  I haven't enabled it on my main
laptop.  I am using a high quality SSD that has a signfican't amount
of internal over-provisioning.

> 6) Added vm.swappiness as kernel option in /etc/sysctl.d/local.conf

There is a lot of FUD concerning swappiness.  I wish there were more
objective data to remove the emotional decision making concerning it.
But the best tuning is different depending upon the workload.
Therefore there isn't any one single canonical correct answer.  But I
think most people use the wrong one.  For my laptop I never have
enough ram and therefore I like more swappiness.

The best tuned answer for you depends upon how much ram you have
available.  I think this article describes it fairly well.

  http://www.linuxvox.com/2009/10/what-is-the-linux-kernel-parameter-vm-swappiness/

Linux-Fan wrote:
> KS wrote:
> > What I want to know at this point is:
> > Is there anything else that is recommended?
> 
> Nothing that I am aware of.

I agree with Linux-Fan's response.  I don't know of anything more that
is needed.  And actually you didn't need to do as much as you have
done.

> > The section on RAMDISK options on tmpfs, does that help?
> 
> As long as your /tmp does not normally exceed your RAM size it might be
> a good idea. Still, it is not really SSD specific: It will of course
> save a few writes, but as long as /tmp is always smaller than your RAM,
> there are obviously not that many writes anyway.

The choice of tmpfs for /tmp or not is somewhat contentious since it
depends upon your use model.  It isn't good for very large (many gigs
exceeding ram size) scratch work areas.  But it is nice for random
small systems.  It is really a personal choice.

As to tuning it specifically for an SSD I wouldn't bother.  I don't
see a need to hold off commits to an SSD for 10 minutes for example.
There isn't any disk to consume power spinning up.  I think that is
really more appropriate for a spinning hard drive than for an SSD.  I
would rather let the file system buffer cache handle that layer.

As with all things actual benchmarks would be best.  But unfortunately
those are few and far between.

> > Lastly, the partition alignment discussion on
> > http://tytso.livejournal.com/2009/02/20/ is from 2009 - is it relevant
> > today?
> 
> Using today's Debian you do not normally need to bother with alignment
> as all partitions will be automatically aligned at 1 MiB boundaries by
> most of the tools anyway.

Agreed.  No need to worry about it with a default Wheezy or later
installation.  All handled automatically.

> > Are any of the above "modifications" really necessary?
> 
> None of the modifications is "necessary". You can simply replace a HDD
> with a SSD without having to worry much. Still, a ramdisk for /tmp could
> be useful (also in HDD environments).

Agreed.  With the current Wheezy Stable or later there isn't really
any need to do anything special.

Bob

Attachment: signature.asc
Description: Digital signature


Reply to: