Има много съвети там, за да променяте SSD в Linux и много анекдотични доклади за това какво работи и какво не. Направихме собствени показатели с няколко конкретни ощипвания, за да ви покажем истинската разлика.
За да сравните нашия диск, използвахме Phoronix Test Suite. Тя е безплатна и има хранилище за Ubuntu, така че не е нужно да събирате от нулата, за да пуснете бързи тестове. Тествахме системата си веднага след нова инсталация на Ubuntu Natty 64-битова, използвайки параметрите по подразбиране за файловата система ext4.
Спецификациите на системата ни бяха, както следва:
И, разбира се, SSD, с който бяхме свикнали, беше 64GB OCZ Onyx drive ($ 117 на Amazon.com по време на писането).
Има доста промени, които хората препоръчват при надстройване до SSD. След като филтрирахме някои от по-старите неща, направихме кратък списък с промените, които Linux дистрибуциите не са включили по подразбиране за SSD. Три от тях включват редактиране на файла fstab, затова преди да продължите със следната команда:
sudo cp / etc / fstab /etc/fstab.bak
Ако нещо се обърка, винаги можете да изтриете новия файл fstab и да го замените с копие от резервното копие. Ако не знаете какво е това, или искате да изтриете как работи, разгледайте HTG обяснява: Какво е fstab на Linux и как работи?
Избягване на часовете за достъп
Можете да помогнете за увеличаване на живота на SSD, като намалите колко OS записва на диска. Ако трябва да знаете кога е бил последният достъп на всеки файл или директория, можете да добавите тези две опции към файла / 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" с буквата на вашето root устройство:
котка / sys / блок / sdX / опашка / планиращо устройство
Моята инсталация е на SDA. Трябва да видите няколко различни опции.
Ако имате краен срок, трябва да използвате това, тъй като ви дава допълнително ощипване надолу по линията. Ако не, трябва да можете да използвате noop без проблеми. Трябва да кажем на операционната система да използва тези опции след всяко зареждане, така че ще трябва да редактираме файла rc.local.
Ще използваме нано, тъй като се чувстваме комфортно с командния ред, но можете да използвате всеки друг текстов редактор, който ви харесва (gedit, vim и т.н.).
sudo nano /etc/rc.local
Над линията "изход 0" добавете тези два реда, ако използвате крайния срок:
крайния ехо> / sys / block / sdX / опашката / планиращия
ехо 1> / sys / блок / sdX / опашка / iosched / fifo_batch
Ако използвате ноуп, добавете следния ред:
echo noop> / sys / block / sdX / опашката / планиращия
За пореден път заменете "X" с подходящата буква за инсталиране. Погледнете всичко, за да сте сигурни, че изглежда добре.
След това натиснете CTRL + O, за да запазите, след което CTRL + X, за да затворите.
Рестартирам
За да влязат в сила всички тези промени, трябва да рестартирате. След това трябва да сте готови. Ако нещо се обърка и не можете да заредите, можете систематично да отмените всяка от горните стъпки, докато не можете отново да заредите. Можете дори да използвате LiveCD или LiveUSB, за да ги възстановите, ако искате.
Промените ви в fstab ще преживеят живота ви, дори и да издържат подобренията, но вашата rc.local промяна ще трябва да бъде възстановена след всяко надстройване (между версиите).
За да изпълним критериите, проведохме тестовете за дискове. Най-горното изображение на всеки тест е преди да промените конфигурацията на ext4, а долната снимка е след ощипването и рестартирането. Ще видите кратко обяснение за това какви са тестовете, както и за тълкуването на резултатите.
Големи операции с файлове
Този тест компресира 2 GB файл с произволни данни и го записва на диск. Измененията на 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 и 512KB. Това симулира уеб сървърите и сървърите за поща доста добре и виждаме 16% увеличение на производителността след промяната.
FS-Mark разглежда 1000 файла с общ размер от 1 МБ и измерва колко могат да бъдат напълно написани и четени в предварително определен период от време. Нашите tweaks виждат увеличение, отново, с по-малки размери на файловете. Около 45% увеличение с корекции на ext4.
Достъп до файлова система
Dbench тества тестовете на файловата система от клиентите, като например как Samba прави нещата. Тук производителността на ванилия ext4 е намалена с 75%, което е основен спад в промените, които направихме.
Можете да видите, че с нарастването на броя на клиентите се увеличава несъответствието в производителността.
С 48 клиента, разликата между тях се е затворила, но все пак има много очевидна загуба на ефективност от нашите ощипвания.
С 128 клиента изпълнението е почти същото. Можете да разберете, че нашите ощипвания може да не са идеални за домашна употреба при този вид операции, но ще осигурят съпоставимо представяне, когато броят на клиентите се увеличи значително.
Този тест зависи от библиотеката за достъп AIO на ядрото. ние имаме 20% подобрение тук.
Тук имаме случайно четене с 64-битови мулти-резбовани файлове и тук има 200% увеличение на производителността! Еха!
Докато пишем 64MB данни с 32 нишки, все още имаме 75% увеличение на производителността.
Compile Bench симулира ефекта от възрастта върху файловата система, представена чрез манипулиране на дърветата на ядрото (създаване, компилиране, копиране и т.н.). Тук можете да видите значителна полза чрез първоначалното създаване на симулирано ядро, около 40%.
Тези показатели просто измерват колко време е необходимо да извлечете Linux ядрото. Не е твърде голямо увеличение на представянето тук.
Корекциите, които направихме в конфигурацията на ext4 от външния вид на Ubuntu, имаха доста голямо въздействие. Най-големите печалби в областта на производителността са в сферите на многобройните пишещи и четения, малките файлови прочитания и големите съседни файлове четат и пишат. Всъщност, единственото истинско място, което видяхме като хит в изпълнението, беше в простите разговори с файловата система, нещо, за което трябва да внимават потребителите на Samba. Като цяло изглежда доста стабилно увеличение на ефективността за неща като хостинг на уеб страници и гледане / стрийминг на големи видеоклипове.
Имайте предвид, че това е специално с Ubuntu Natty 64-битов. Ако вашата система или SSD е различна, пробегът ви може да варира. Като цяло, обаче, изглежда, че настройките на fstab и IO scheduler, които направихме, вървят далеч по-добре, затова вероятно си струва да опитате на собствената си платформа.
Имате ли ваши критерии и искате да споделите резултатите си? Имате още едно ощипване, за което не знаем? Звучи в коментарите!
