Активна робота із записом на продуктивності системи ядер SSD

Я помітив, що коли я пишу важкі програми, вся система сповільнюється. Щоб перевірити це далі, я запустив це, щоб зробити (відносно) низький процесор, з високою активністю диска:

john -incremental > file_on_SSD

Це викачує десятки тисяч рядків у секунду до файлу на моєму системному диску.

Коли це робиться, миша відстає, TTY стають невідповідними, програми "зникають" і загалом весь комп'ютер стає непридатним. Коли я можу в підсумку Control + C john, система повертається на повну силу через кілька секунд.

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

Мій основний диск з ОС - досить швидкий SSD ( OCZ Agility 60 Гб ) з EXT4. Якщо я johnзаписую висновок на механічний диск з EXT4, я не відчуваю таких самих уповільнень, хоча швидкість набагато повільніше (SSD - ~ 42000 слів в секунду, механічний - 8000 Вт / с). Пропускна здатність може бути доречною. Механічний диск також не має нічого спільного з системою. Це просто дані.

І я використовую ядро ​​2.6.35-2, але я помітив цю проблему з моменту отримання цього SSD, коли я, ймовірно, використовував .31 або щось із цього часу.

Отже, що викликає уповільнення? Випуск EXT4? Випуск ядра? Випуск SSD? Все вищеперераховане? Щось ще?

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

Це було відомим питанням деякий час. Використання налаштованого на SSD FS типу Btrfs може допомогти, але це не може.

Зрештою, це помилка в системах планування вводу-виводу / управління пам’яттю. Останнім часом з’явилися деякі патчі, які спрямовані на вирішення цього питання. Див. Виправлено: Проблема з чутливістю до робочого столу Linux?

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

Ви можете перевірити кілька речей, щоб спробувати покращити продуктивність SSD під Linux.

1. Встановіть точку кріплення на "noatime". Додаткова активність оновлення часу доступу, як правило, витрачається на більшість випадків використання. Особливо у випадку постійного завантаження окремих рядків у файл, ви змушуєте кілька оновлень файлової системи для кожного доступу.

2. Перевірте ліфт. Ліфт за замовчуванням для більшості дистрибутивів встановлюється для обертових блюд із випадковим доступом. SSD не потребує додаткової логіки, тому встановлення ліфта на нооп може покращити продуктивність, дозволяючи апаратурі керувати записами.

3. Програмування кешування зворотного запису v. Це трохи езотеричніше, але ви можете перевірити метод кешування, який використовується hdparmдля пристрою. Кешування зворотного запису може мати позитивний вплив на продуктивність SSD порівняно з проходом запису.

Кешування файлів, ймовірно, неправильно налаштоване на навантаження. На жаль, ядро ​​Linux досить дурне, щоб не справлятися з цим автоматично, а типові параметри є досить поганими, якщо у вас багато оперативної пам’яті та досить повільних блокових пристроїв. Докладніше дивіться на https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ .

Я б запропонував спробувати змінити /etc/sysctl.confбудь-яку

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

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

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

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

Зауважте, що *_ratioналаштування стосуються відсотка доступної оперативної пам’яті. Якщо ви хочете краще контролювати, скористайтеся *_bytesналаштуваннями. Я особисто використовую таку конфігурацію для своєї робочої станції:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

Це обмежує кеш запису фоном до 50 Мб і змушує синхронне записування, якщо в кеш-пам'яті знаходиться 200 МБ.