Как да настроите SSD в Ubuntu за по-добра производителност

Има много съвети за настройване на вашия SSD в Linux и много анекдотични доклади за това какво работи и какво не. Проведохме собствени бенчмаркове с няколко специфични настройки, за да ви покажем истинската разлика.

Показатели

За да сравним нашия диск, използвахме тестовия пакет Phoronix. Това е безплатно и има хранилище за Ubuntu, така че не е нужно да компилирате от нулата, за да изпълнявате бързи тестове. Тествахме нашата система веднага след нова инсталация на 64-битова версия на Ubuntu Natty, използвайки параметрите по подразбиране за файловата система ext4.

Нашите системни характеристики бяха следните:

• Четириядрен процесор AMD Phenom II на 3.2 ГХц
• Дънни платки MSI 760GM E51
• 3.5 GB RAM
• AMD Radeon 3000 интегриран с 512MB RAM
• Ubuntu Natty

И, разбира се, SSD, който използвахме за тестване беше 64GB OCZ Onyx диск ($ 117 на Amazon.com по време на писане).

Изтъкнати промени

Има доста промени, които хората препоръчват при обновяване до SSD. След като филтрирахме някои от по-старите неща, направихме кратък списък с настройки, които дистрибуциите на Linux не са включени като стандартни за SSD. Три от тях включват редактиране на вашия fstab файл, така че се върнете обратно, преди да продължите със следната команда:

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

Ако нещо се обърка, винаги можете да изтриете новия fstab файл и да го замените с копие на архива. Ако не знаете какво е това или искате да разберете как работи, погледнете HTG Обяснява: Какво е fstab на Linux и как работи?

Избягване на времето за достъп

Можете да помогнете за увеличаване на живота на вашия SSD, като намалите броя на записаната на операционната система операционна система. Ако трябва да знаете кога всеки файл или директория е бил достъпен за последен път, можете да добавите тези две опции във вашия файл / etc / fstab:

noatime, nodiratime

Добавете ги заедно с другите опции и се уверете, че всички са разделени със запетаи и без интервали.

Активиране на TRIM

Можете да активирате TRIM, за да помогнете за управление на производителността на диска в дългосрочен план. Добавете следната опция към вашия fstab файл:

изхвърлете

Това работи добре за файловите системи ext4, дори и за стандартните твърди дискове. Трябва да имате версия на ядрото поне 2.6.33 или по-нова; покрити сте, ако използвате Maverick или Natty, или имате backports активиран на Lucid. Макар това да не подобрява специфично първоначалния бенчмаркинг, то трябва да направи системата по-добра в дългосрочен план и така тя направи списъка ни.

Tmpfs

Системният кеш се съхранява в / tmp. Можем да кажем на fstab да монтира това в RAM като временна файлова система, така че вашата система да докосне по-малко твърдия диск. Добавете следния ред в дъното на файла / etc / fstab в нов ред:

tmpfs / tmp tmpfs по подразбиране, noatime, mode = 1777 0 0

Запазете вашия fstab файл, за да извършите тези промени.

Превключване на IO Schedulers

Системата ви не записва незабавно всички промени на диска и много заявки се поставят на опашка. Подразбиращият се входен-изходен планировчик - cfq - обработва това добре, но можем да го променим на такъв, който работи по-добре за хардуера ни.

Първо избройте кои опции имате на разположение със следната команда, като замените „X“ с буквата на основния диск:

cat / sys / block / sdX / queue / scheduler

Инсталацията ми е на sda. Трябва да видите няколко различни опции.

Ако имате краен срок, трябва да го използвате, тъй като ви дава допълнителна промяна по-нататък. Ако не, трябва да можете да използвате noop без проблеми. Трябва да кажем на операционната система да използва тези опции след всяко зареждане, така че ще трябва да редактираме файла rc.local.

Ще използваме nano, тъй като сме доволни от командния ред, но можете да използвате всеки друг текстов редактор, който ви харесва (gedit, vim и др.).

sudo nano /etc/rc.local

Над реда „exit 0“ добавете тези два реда, ако използвате краен срок:

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

echo 1> / sys / block / sdX / опашка / iosched / fifo_batch

Ако използвате noop, добавете този ред:

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

Още веднъж сменете "X" с подходящата буква на устройството. Погледнете всичко, за да се уверите, че изглежда добре.

След това натиснете CTRL + O, за да запазите, след това CTRL + X, за да излезете.

Рестартирам

За да влязат в сила всички тези промени, трябва да рестартирате. След това трябва да сте готови. Ако нещо се обърка и не можете да стартирате, можете системно да отмените всяка от горните стъпки, докато не стартирате отново. Можете дори да използвате LiveCD или LiveUSB за възстановяване, ако желаете.

Промените във вашата fstab ще продължат до края на живота на инсталацията ви, дори да издържат на подобренията, но вашата промяна на rc.local ще трябва да бъде възстановена след всяко ъпгрейд (между версии)..

Резултати от бенчмаркинга

За да изпълним бенчмарковете, стартирахме набор от тестове. Най-горното изображение на всеки тест е преди настройката на ext4 конфигурацията, а най-долното изображение е след настройките и рестартирането. Ще видите кратко обяснение за това какви са мерките за изпитване, както и интерпретация на резултатите.

Големи файлови операции

Този тест компресира 2GB файл със случайни данни и го записва на диск. Подобренията в SSD показват 40% подобрение.

IOzone симулира производителността на файловата система, като в този случай пише 8GB файл. Отново, почти 50% увеличение.

Тук се чете 8GB файл. Резултатите са почти същите като без настройка ext4.

AIO-Stress асинхронно тества входа и изхода, използвайки 2GB тестов файл и 64KB размер на записа. Тук има почти 200% увеличение на производителността в сравнение с ванилия ext4!

Операции с малки файлове

Създава се SQLite база данни и PTS добавя към нея 12,500 записа. SSD ощипванията всъщност забавиха производителността с около 10%.

Apache Benchmark тества произволни четения на малки файлове. Налице е около 25% увеличение на производителността след оптимизиране на SSD.

PostMark симулира 25 000 транзакции с файлове, 500 едновременно във всеки даден момент, с размери на файловете между 5 и 512 КБ. Това симулира доста добре уеб сървъри и сървъри за поща, а ние виждаме 16% увеличение на производителността след настройката.

FS-Mark разглежда 1000 файла с общ размер 1MB и измерва колко от тях могат да бъдат изцяло написани и прочетени в предварително определено време. Нашите промени показват увеличение, отново с по-малки размери на файлове. Около 45% нарастват с корекциите ext4.

Достъп до файлова система

Dbench тестовете тестват извиквания на файловата система от клиенти, нещо като как Samba прави нещата. Тук представянето на ванилия ext4 се намалява с 75%, което е основен спад в промените, които направихме.

Можете да видите, че с нарастването на броя на клиентите, несъответствието в производителността нараства.

С 48 клиента, разликата се затвори малко между двете, но все още има много очевидна загуба на производителност от нашите настройки.

С 128 клиента производителността е почти същата. Можете да кажете, че нашите настройки не са идеални за домашна употреба в този вид операция, но ще осигурят сравними резултати, когато броят на клиентите е значително увеличен.

Този тест зависи от библиотеката за достъп AIO на ядрото. тук имаме 20% подобрение.

Тук имаме четене на 64MB с много нишки и имаме 200% увеличение на производителността тук! Еха!

Докато записваме 64MB данни с 32 нишки, все още имаме 75% увеличение на производителността.

Compile Bench симулира ефекта от възрастта върху файловата система, представена чрез манипулиране на дърветата на ядрото (създаване, компилиране, корегиране и др.). Тук можете да видите значителна полза от първоначалното създаване на симулираното ядро, около 40%.

Този бенчмарк просто измерва колко време е необходимо за извличане на ядрото на Linux. Не е прекалено много за повишаване на производителността тук.

резюме

Корекциите, които направихме за външната конфигурация ext4 на Ubuntu, имаха доста голямо влияние. Най-големите печалби от производителността бяха в сферите на многонишковите записи и четения, малките четения на файлове и големите съседни файлове четат и пишат. Всъщност, единственото реално място, на което видяхме хит в изпълнението е било в прости повиквания за файлова система, за което потребителите на Samba трябва да внимават. Като цяло изглежда, че това е доста солидно увеличение на производителността за неща като хостинг уеб страници и гледане / стрийминг на големи видеоклипове.

Имайте предвид, че това е специално с 64-битовата версия на Ubuntu Natty. Ако вашата система или SSD е различна, вашият пробег може да варира. Като цяло обаче изглежда, че корекциите на fstab и IO Scheduler, които направихме, са много добри за по-добра производителност, така че вероятно си струва да опитате на собствената си платформа..

Имате свои собствени показатели и искате да споделите резултатите си? Имате ли друга настройка, за която не знаем? Звучи в коментарите!