ubuntu 装在ssd_如何在Ubuntu中调整SSD以提高性能

ubuntu 装在ssd

There are lots of tips out there for tweaking your SSD in Linux and lots of anecdotal reports on what works and what doesn’t. We ran our own benchmarks with a few specific tweaks to show you the real difference.

有很多技巧可用于在Linux中调整SSD，以及有关有效和无效的大量报道。 我们通过一些特定的调整运行了自己的基准，以向您展示真正的差异。

基准测试 (Benchmarks)

To benchmark our disk, we used the Phoronix Test Suite. It’s free and has a repository for Ubuntu so you don’t have to compile from scratch to run quick tests. We tested our system right after a fresh installation of Ubuntu Natty 64-bit using the default parameters for the ext4 file system.

为了对磁盘进行基准测试，我们使用了Phoronix测试套件 。 它是免费的，并且具有Ubuntu的存储库，因此您无需从头编译即可运行快速测试。 在使用ext4文件系统的默认参数全新安装Ubuntu Natty 64位之后，我们立即测试了系统。

Our system specs were as follows:

我们的系统规格如下：

• AMD Phenom II quad-core @ 3.2 GHz
  AMD Phenom II四核@ 3.2 GHz
• MSI 760GM E51 motherboard
  微星760GM E51主板
• 3.5 GB RAM
  3.5 GB内存
• AMD Radeon 3000 integrated w/ 512MB RAM
  集成512MB RAM的AMD Radeon 3000
• Ubuntu Natty
  Ubuntu的纳蒂

And, of course, the SSD we used to test on was a 64GB OCZ Onyx drive ($117 on Amazon.com at time of writing).

而且，当然，我们用来测试的SSD是64GB OCZ Onyx驱动器(在撰写本文时在Amazon.com上为117美元 )。

突出的调整 (Prominent Tweaks)

There are quite a few changes that people recommend when upgrading to an SSD. After filtering out some of the older stuff, we made a short list of tweaks that Linux distros have not included as defaults for SSDs. Three of them involve editing your fstab file, so back that up before you continue with the following command:

人们在升级到SSD时建议进行很多更改。 在过滤掉一些较旧的内容之后，我们列出了一些简短的调整，Linux发行版并未将这些调整作为SSD的默认值。 其中三个涉及编辑fstab文件，因此请在继续以下命令之前先进行备份：

sudo cp /etc/fstab /etc/fstab.bak

须藤cp / etc / fstab /etc/fstab.bak

If something goes wrong, you can always delete the new fstab file and replace it with a copy of your backup. If you don’t know what that is or you want to brush up on how it works, take a look at HTG Explains: What is the Linux fstab and How Does It Work?

如果出现问题，您始终可以删除新的fstab文件，并用备份副本替换它。 如果您不知道这是什么，或者想重新了解它是如何工作的，请查看HTG解释：什么是Linux fstab以及它如何工作？

Eschewing Access Times

避开访问时间

You can help increase the life of your SSD by reducing how much the OS write to disk. If you need to know when each file or directory was last accessed, you can add these two options to your /etc/fstab file:

您可以通过减少操作系统写入磁盘的数量来帮助延长SSD的寿命。 如果您需要知道上次访问每个文件或目录的时间，可以将以下两个选项添加到/ etc / fstab文件中：

noatime,nodiratime

noatime，nodiratime

Add them along with the other options, and make sure they’re all separated by commas and no spaces.

将它们与其他选项一起添加，并确保它们之间都用逗号分隔且没有空格。

Enabling TRIM

启用TRIM

You can enable TRIM to help manage disk performance over the long-term. Add the following option to your fstab file:

您可以启用TRIM来帮助长期管理磁盘性能。 将以下选项添加到您的fstab文件中：

discard

丢弃

This works well for ext4 file systems, even on standard hard drives. You must have a kernel version of at least 2.6.33 or later; you’re covered if you’re using Maverick or Natty, or have backports enabled on Lucid. While this doesn’t specifically improve initial benchmarking, it should make the system perform better in the long-run and so it made our list.

即使在标准硬盘驱动器上，这对于ext4文件系统也很有效。 您的内核版本必须至少为2.6.33或更高； 如果您使用的是Maverick或Natty，或者在Lucid上启用了反向端口，则可以满足您的要求。 尽管这并不能专门改善初始基准测试，但从长远来看，应该可以使系统性能更好，因此成为我们的榜单。

Tmpfs

Tmpfs

The system cache is stored in /tmp. We can tell fstab to mount this in the RAM as a temporary file system so your system will touch the hard drive less. Add the following line to the bottom of your /etc/fstab file in a new line:

系统缓存存储在/ tmp中。 我们可以告诉fstab将其作为临时文件系统挂载在RAM中，这样您的系统将减少与硬盘的接触。 将以下行添加到/ etc / fstab文件底部的新行中：

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

tmpfs / tmp tmpfs默认值，noatime，模式= 1777 0 0

Save your fstab file to commit these changes.

保存您的fstab文件以提交这些更改。

Switching IO Schedulers

切换IO调度程序

Your system doesn’t write all changes to disk immediately, and multiple requests get queued. The default input-output scheduler – cfq – handles this okay, but we can change this to one that works better for our hardware.

您的系统不会立即将所有更改写入磁盘，并且多个请求会排队。 默认的输入输出调度程序cfq可以解决此问题，但是我们可以将其更改为对我们的硬件更有效的调度程序。

First, list which options you have available with the following command, replacing “X” with the letter of your root drive:

首先，使用以下命令列出可用的选项，用根驱动器的盘符替换“ X”：

cat /sys/block/sdX/queue/scheduler

猫/ sys / block / sdX / queue / scheduler

My installation is on sda. You should see a few different options.

我的安装在sda上。 您应该看到几个不同的选项。

If you have deadline, you should use that, as it gives you an extra tweak further down the line. If not, you should be able to use noop without problems. We need to tell the OS to use these options after every boot so we’ll need to edit the rc.local file.

如果您有截止日期，则应该使用截止日期，因为这会给您带来进一步的调整。 如果没有，您应该可以使用noop而不会出现问题。 我们需要告诉操作系统在每次引导后使用这些选项，因此我们需要编辑rc.local文件。

We’ll use nano, since we’re comfortable with the command-line, but you can use any other text editor you like (gedit, vim, etc.).

因为我们对命令行很满意，所以我们将使用nano，但是您可以使用任何您喜欢的其他文本编辑器(gedit，vim等)。

sudo nano /etc/rc.local

须藤nano /etc/rc.local

Above the “exit 0” line, add these two lines if you’re using deadline:

如果您使用的是截止日期，请在“退出0”行上方添加以下两行：

echo deadline > /sys/block/sdX/queue/scheduler

回声截止日期> / sys / block / sdX / queue / scheduler

echo 1 > /sys/block/sdX/queue/iosched/fifo_batch

回声1> / sys / block / sdX / queue / iosched / fifo_batch

If you’re using noop, add this line:

如果您使用的是noop，请添加以下行：

echo noop > /sys/block/sdX/queue/scheduler

echo noop> / sys / block / sdX / queue / scheduler

Once again, replace “X” with the appropriate drive letter for your installation. Look over everything to make sure it looks good.

再次用适合您安装的驱动器号替换“ X”。 查看所有内容以确保它看起来不错。

Then, hit CTRL+O to save, then CTRL+X to quit.

然后，按CTRL + O保存，然后按CTRL + X退出。

Restart

重新开始

In order for all these changes to go into effect, you need to restart. After that, you should be all set. If something goes wrong and you can’t boot, you can systematically undo each of the above steps until you can boot again. You can even use a LiveCD or LiveUSB to recover if you want.

为了使所有这些更改生效，您需要重新启动。 之后，您应该已经准备就绪。 如果出现问题而无法启动，则可以系统地撤消上述每个步骤，直到可以再次启动为止。 如果需要，您甚至可以使用LiveCD或LiveUSB进行恢复 。

Your fstab changes will carry through the life of your installation, even withstanding upgrades, but your rc.local change will have to be re-instituted after every upgrade (between versions).

您的fstab更改将贯穿安装的整个生命周期，即使可以进行升级，但每次升级后(版本之间)都必须重新安装rc.local更改。

基准测试结果 (Benchmarking Results)

To perform the benchmarks, we ran the disk suite of tests. The top image of each test is before tweaking the ext4 configuration, and the bottom image is after the tweaks and a reboot. You’ll see a brief explanation of what the test measures as well as an interpretation of the results.

为了执行基准测试，我们运行了磁盘测试套件。 每个测试的顶部图像是在调整ext4配置之前，底部图像是在调整和重新启动之后。 您将看到有关测试方法的简要说明以及结果的说明。

Large File Operations

大文件操作

This test compresses a 2GB file with random data and writes it to disk. The SSD tweaks here show in a roughly 40% improvement.

此测试使用随机数据压缩2GB文件并将其写入磁盘。 此处显示的SSD调整大约有40％的改善。

IOzone simulates file system performance, in this case by writing an 8GB file. Again, an almost 50% increase.

IOzone通过写入8GB文件来模拟文件系统性能。 同样，增加了将近50％。

Here, an 8GB file is read. The results are almost the same as without adjusting ext4.

在这里，读取了8GB的文件。 结果几乎与不调整ext4相同。

AIO-Stress asynchronously tests input and output, using a 2GB test file and a 64KB record size. Here, there’s almost a 200% increase in performance compared to vanilla ext4!

AIO-Stress使用2GB的测试文件和64KB的记录大小来异步测试输入和输出。 与香草ext4相比，这里的性能几乎提高了200％！

Small File Operations

小文件操作

An SQLite database is created and PTS adds 12,500 records to it. The SSD tweaks here actually slowed down performance by about 10%.

创建一个SQLite数据库，PTS向其中添加12,500条记录。 SSD的调整实际上使性能降低了约10％。

The Apache Benchmark tests random reads of small files. There was about a 25% performance gain after optimizing our SSD.

Apache Benchmark测试小文件的随机读取。 优化我们的固态硬盘后，性能提高了约25％。

PostMark simulates 25,000 file transactions, 500 simultaneously at any given time, with file sizes between 5 and 512KB. This simulates web and mail servers pretty well, and we see a 16% performance increase after tweaking.

PostMark模拟25,000个文件事务，在任何给定时间同时仿真500个，文件大小在5到512KB之间。 这样可以很好地模拟Web和邮件服务器，并且在进行调整后，我们看到性能提高了16％。

FS-Mark looks at 1000 files with a  total size of 1MB, and measures how many can be completely written and read in a pre-ordained amount of time. Our tweaks see an increase, again, with smaller file sizes. About a 45% increase with ext4 adjustments.

FS-Mark查看1000个文件，总大小为1MB，并测量在预定时间内可以完全写入和读取的文件数量。 我们的调整再次导致文件大小减小了。 使用ext4调整时大约增加了45％。

File System Access

文件系统访问

The Dbench benchmarks test file system calls by clients, sort of like how Samba does things. Here, vanilla ext4’s performance is cut by 75%, a major set-back in the changes we made.

Dbench基准测试由客户端测试文件系统调用，类似于Samba的工作方式。 在这里，香草ext4的性能降低了75％，这是我们所做更改的重大挫折。

You can see that as the number of clients goes up, the performance discrepancy increases.

您可以看到，随着客户端数量的增加，性能差异也会增加。

With 48 clients, the gap closed somewhat between the two, but there’s still a very obvious performance loss by our tweaks.

在拥有48个客户的情况下，两者之间的差距有所缩小，但是由于我们的调整，性能仍然明显下降。

With 128 clients, the performance is almost the same. You can reason that our tweaks may not be ideal for home use in this kind of operation, but will provide comparable performance when the number of clients is greatly increased.

在128个客户端的情况下，性能几乎是相同的。 您可能会认为，我们的调整可能不适用于这种操作的家庭使用，但是当客户数量大大增加时，它将提供可比的性能。

This test depends on the kernel’s AIO access library. we’ve got a 20% improvement here.

此测试取决于内核的AIO访问库。 我们在这里有20％的改善。

Here, we have a multi-threaded random read of 64MB, and there’s a 200% increase in performance here! Wow!

在这里，我们有64MB的多线程随机读取，并且这里的性能提高了200％！ 哇！

While writing 64MB of data with 32 threads, we still have a 75% increase in performance.

使用32个线程写入64MB数据时，我们的性能仍然提高了75％。

Compile Bench simulates the effect of age on a file system as represented by manipulating kernel trees (creating, compiling, patching, etc.). Here, you can see a significant benefit through the initial creation of the simulated kernel, about 40%.

编译工作台模拟了文件系统上年龄的影响，以操纵内核树(创建，编译，打补丁等)为代表。 在这里，您可以看到通过初始创建模拟内核而获得的显着收益，约为40％。

This benchmarks simply measures how long it takes to extract the Linux kernel. Not too much of an increase in performance here.

该基准测试仅测量提取Linux内核所需的时间。 这里的性能提升不是太多。

摘要 (Summary)

The adjustments we made to Ubuntu’s out-of-the-box ext4 configuration did have quite an impact. The biggest performance gains were in the realms of multi-threaded writes and reads, small file reads, and large contiguous file reads and writes. In fact, the only real place we saw a hit in performance was in simple file system calls, something Samba users should watch out for. Overall, it seems to be a pretty solid increase in performance for things like hosting webpages and watching/streaming large videos.

我们对Ubuntu的现成ext4配置所做的调整确实产生了很大的影响。 最大的性能提升是在多线程写入和读取，小型文件读取以及大型连续文件读取和写入领域。 实际上，我们看到的唯一真正影响性能的地方就是简单的文件系统调用，这是Samba用户应该注意的。 总体而言，托管网页和观看/流式传输大型视频等内容的性能似乎有了可观的增长。

Keep in mind that this was specifically with Ubuntu Natty 64-bit. If your system or SSD is different, your mileage may vary. Overall though, it seems as though the fstab and IO scheduler adjustments we made go a long way to better performance, so it’s probably worth a try on your own rig.

请记住，这是专门针对64位Ubuntu Natty的。 如果您的系统或SSD不同，则里程可能会有所不同。 总体而言，似乎我们对fstab和IO调度程序所做的调整对提高性能有很长的路要走，因此值得在您自己的设备上尝试一下。

Have your own benchmarks and want to share your results? Have another tweak we don’t know about? Sound out in the comments!

有自己的基准，并希望分享您的结果吗？ 还有我们不知道的另一项调整吗？ 声音在评论中！

翻译自: https://www.howtogeek.com/62761/how-to-tweak-your-ssd-in-ubuntu-for-better-performance/

ubuntu 装在ssd