Як налаштувати ваш SSD в Ubuntu для покращення продуктивності

Є багато порад для налаштування вашого SSD в Linux і багато анекдотичних звітів про те, що працює, а що ні. Ми провели наші власні тести з кількома конкретними налаштуваннями, щоб показати вам реальну різницю.

Тести

Для тестування нашого диска ми використали тестовий набір Phoronix. Це безкоштовно і має репозиторій для Ubuntu, тому вам не доведеться компілювати з нуля для запуску швидких тестів. Ми перевірили нашу систему відразу після встановлення 64-бітної версії Ubuntu Natty, використовуючи параметри за замовчуванням для файлової системи ext4.

Наші системні специфікації були такими:

• Чотирьохядерний процесор AMD Phenom II на 3,2 ГГц
• Материнська плата MSI 760GM E51
• 3,5 Гб оперативної пам'яті
• AMD Radeon 3000 інтегрований з 512 Мб оперативної пам'яті
• Ubuntu Natty

І, звичайно, SSD, який ми використовували для тестування, був привід OCZ Onyx на 64 ГБ ($ 117 на Amazon.com на момент написання).

Видатні налаштування

Існує чимало змін, які люди рекомендують під час оновлення до SSD. Після фільтрування деяких старих матеріалів, ми зробили короткий список налаштувань, які дистрибутиви Linux не включили як стандартні для SSD. Три з них передбачають редагування файлу fstab, тому поверніть його, перш ніж продовжити наступну команду:

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

Якщо щось піде не так, ви завжди можете видалити новий файл fstab і замінити його копією резервної копії. Якщо ви не знаєте, що це таке, або ви хочете зачекати, як він працює, подивіться на HTG Пояснює: Що таке Linux fstab і як це працює?

Повільний час доступу

Ви можете допомогти збільшити термін служби вашого SSD, зменшивши кількість записів операційної системи на диск. Якщо вам потрібно знати, коли кожний з файлів або каталогів останній доступний, ви можете додати ці два параметри до вашого файлу / etc / fstab:

noatime, нодіратіме

Додайте їх разом з іншими параметрами та переконайтеся, що всі вони розділені комами та без пробілів.

Увімкнення TRIM

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

відкинути

Це добре працює для файлових систем ext4, навіть на стандартних жорстких дисках. Ви повинні мати версію ядра не менше 2.6.33 або пізнішої; Ви охоплені, якщо ви використовуєте Maverick або Natty, або увімкнено backports на Lucid. Хоча це не сприяє покращенню початкового бенчмаркінгу, воно повинно зробити систему більш ефективною в довгостроковій перспективі, і тому вона стала нашим списком.

Tmpfs

Системний кеш зберігається в / tmp. Ми можемо наказати fstab змонтувати це в оперативній пам'яті як тимчасову файлову систему, щоб ваша система торкнулася жорсткого диска менше. Додайте наступний рядок до нижньої частини файлу / 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 / queue / iosched / fifo_batch

Якщо ви використовуєте noop, додайте цей рядок:

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

Знову замінити "X" на відповідну букву диска для встановлення. Подивіться на все, щоб переконатися, що він добре виглядає.

Потім натисніть CTRL + O, щоб зберегти, потім CTRL + X, щоб вийти.

Перезапустити

Для того, щоб всі ці зміни набули чинності, потрібно перезапустити. Після цього, ви повинні бути всі налаштовані. Якщо щось піде не так, і ви не можете завантажитися, ви можете систематично скасувати кожен із зазначених вище кроків, доки ви не зможете завантажити його знову. Ви навіть можете використовувати LiveCD або LiveUSB для відновлення, якщо хочете.

Ваші зміни в fstab будуть проходити через життя вашої інсталяції, навіть витримуючи оновлення, але ваша зміна rc.local повинна бути відновлена ​​після кожного оновлення (між версіями).

Результати порівняльного аналізу

Для виконання тестів ми запустили тестовий набір дисків. Верхнє зображення кожного тесту перед тим, як налаштувати конфігурацію ext4, а нижнє зображення - після налаштувань і перезавантаження. Ви побачите коротке пояснення того, які тестові заходи, а також інтерпретація результатів.

Великі операції з файлами

Цей тест стискає 2 Гб файлу з випадковими даними і записує його на диск. Налаштування SSD тут показують приблизно 40% поліпшення.

IOzone імітує продуктивність файлової системи, в даному випадку, шляхом запису файлу 8 Гб. Знову ж таки, майже на 50% більше.

Тут читається файл розміром 8 Гб. Результати майже такі ж, як без коригування ext4.

AIO-Stress асинхронно перевіряє вхід і вихід, використовуючи тестовий файл 2 Гб і розмір запису 64 Кб. Тут майже на 200% збільшилася продуктивність у порівнянні з ванільним ext4!

Операції з малими файлами

Створюється база даних SQLite, і PTS додає до нього 12500 записів. Налаштування SSD тут фактично уповільнили продуктивність приблизно на 10%.

Apache Benchmark перевіряє випадкові читання невеликих файлів. Після оптимізації SSD ми отримали приблизно 25% приросту продуктивності.

PostMark моделює 25000 транзакцій файлів, одночасно 500 у будь-який момент часу, з розмірами файлів від 5 до 512 Кб. Це симулює веб-і поштових серверів досить добре, і ми бачимо 16% підвищення продуктивності після налаштування.

FS-Mark переглядає 1000 файлів загальним розміром 1 Мб і вимірює, скільки їх можна повністю записати і прочитати за заздалегідь визначеною кількістю часу. Наші налаштування, знову ж таки, збільшуються з меншими розмірами файлів. Приблизно на 45% зростає коригування ext4.

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

Тести Dbench перевіряють виклики файлової системи клієнтами, подібно до того, як Samba робить справи. Тут, продуктивність ванільного ext4 скорочується на 75%, що є серйозним відхиленням від змін, які ми внесли.

Ви можете бачити, що зі збільшенням кількості клієнтів збільшується невідповідність продуктивності.

З 48 клієнтами, проміжок закрився дещо між двома, але все ще дуже очевидні втрати продуктивності від наших налаштувань.

З 128 клієнтами продуктивність майже однакова. Ви можете обґрунтувати, що наші налаштування можуть бути не ідеальними для домашнього використання в таких операціях, але забезпечать порівнянну продуктивність, коли кількість клієнтів значно збільшиться.

Цей тест залежить від бібліотеки доступу AIO ядра. у нас тут 20% поліпшення.

Тут ми маємо багатопотоковий читання 64 Мб, і тут продуктивність на 200% більше! Ого!

При написанні 64 Мб даних з 32 потоками, ми все ще маємо 75% збільшення продуктивності.

Компіляція Bench імітує вплив віку на файлову систему, як це представлено маніпулюванням деревами ядра (створення, компіляція, виправлення і т.д.). Тут можна побачити значну вигоду через початкове створення імітованого ядра, близько 40%.

Ці тести просто вимірюють, скільки часу потрібно для вилучення ядра Linux. Не надто багато збільшення продуктивності тут.

Резюме

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

Майте на увазі, що це було конкретно з 64-бітною версією Ubuntu Natty. Якщо ваша система або SSD відрізняється, ваш пробіг може змінюватися. В цілому, здається, що налаштування fstab і IO планувальників, які ми зробили, пройшли довгий шлях до кращої продуктивності, тому, напевно, варто спробувати на власному пристрої.

Маєте свої власні орієнтири та хочете поділитися своїми результатами? Чи є ще одна настройка, про яку ми не знаємо? Звучить в коментарях!