Поліпшення продуктивності кеш-диска в цілому більше, ніж просто збільшення розміру кешу файлової системи, якщо вся ваша система не вписується в оперативну пам’ять. У цьому випадку ви повинні використовувати диск RAM ( tmpfsце добре, оскільки дозволяє повернутися на диск, якщо вам потрібна оперативна пам’ять в деяких випадках) для зберігання часу виконання (і, можливо, сценарій initrd для копіювання системи зі сховища на диск RAM при запуску).
Ви не сказали, чи ваш пристрій зберігання даних - це SSD або HDD. Ось що я знайшов роботу для мене (в моєму випадку sdaце HDD , встановлений на /homeі sdbє SSD встановлений на /).
Спочатку оптимізуйте частину завантаження даних із зберігання в кеш:
Ось моя установка для жорсткого диска (переконайтеся, що AHCI + NCQ увімкнено в BIOS, якщо у вас є перемикачі):
echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda
Варто зауважити, що для корпусу жорсткого диска є високий fifo_expire_async(як правило, запис) і тривалий, slice_syncщоб дозволити одному процесу отримати високу пропускну здатність (встановити slice_syncна нижчу кількість, якщо ви потрапляєте в ситуації, коли кілька процесів чекають паралельно деяких даних з диска). Це slice_idleзавжди є компромісом для жорстких дисків, але встановлення його десь у діапазоні 3-20 повинно бути нормальним залежно від використання диска та мікропрограмного забезпечення диска. Я вважаю за краще орієнтуватися на низькі значення, але встановлення його занадто низьке знищить вашу пропускну здатність. quantumУстановка , здається, впливає на пропускну здатність багато , але спробувати зберегти це якомога менше , щоб зберегти час очікування на розумному рівні. Якщо quantumзанадто низька установка знищить пропускну здатність. Значення в діапазоні 3-8, здається, добре працюють із жорсткими дисками. Найгірший час затримки для читання - ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms, якщо я правильно зрозумів поведінку ядра. Асинхроніка в основному використовується при записі, і оскільки ви готові затримати запис на диску, встановіть як slice_async_rqі slice_asyncдуже низькі числа. Однак встановлення slice_async_rqзанадто низького значення може зупинити зчитування, оскільки запис вже не може затягуватися після читання. Мій конфігуратор спробує записати дані на диск максимум через 10 секунд після передачі даних в ядро, але оскільки ви можете терпіти втрату даних про втрату потужності, також встановлено, fifo_expire_asyncщо 3600000потрібно сказати, що 1 годину в порядку для затримки на диску. slice_asyncОднак просто тримайте низький рівень, тому що в іншому випадку ви можете отримати високу затримку читання.
hdparmКоманда необхідна для запобігання AAM від вбивства здебільшого продуктивності , що дозволяє AHCI + NCQ. Якщо ваш диск видає занадто багато шуму, пропустіть це.
Ось моя настройка для SSD (Intel 320 серія):
echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync
Тут варто відзначити низькі значення для різних параметрів зрізу. Найважливіший параметр для SSD - slice_idleце встановити значення 0-1. Якщо встановити його на нуль, всі рішення про впорядкування переміщуються до рідного NCQ, встановивши його в 1, ядро дозволяє замовляти запити (але якщо NCQ активний, апаратне забезпечення може частково змінювати впорядкування ядра). Перевірте обидва значення, щоб побачити, чи можете ви бачити різницю. Для Intel серії 320, це здається , що установка slide_idleна 0дає найкращу продуктивність , але установка його 1дає кращий ( самий низький) загальне час очікування.
Для отримання додаткової інформації про ці налаштування див. Http://www.linux-mag.com/id/7572/ .
Тепер, коли ми налаштували ядро для завантаження матеріалів з диска в кеш з розумною продуктивністю, настав час коригувати поведінку кешу:
Відповідно до тестів, які я зробив, я взагалі не переймався б налаштуванням читання вперед blockdev. Налаштування ядра за замовчуванням добре.
Встановіть систему, щоб віддавати перевагу обміну файловими даними над кодом програми (це не має значення, чи є у вас достатньо оперативної пам’яті, щоб зберегти всю файлову систему та весь код програми та всю віртуальну пам’ять, виділену програмами в оперативній пам’яті). Це зменшує затримку для заміни між різними програмами над затримкою для доступу до великих файлів з однієї програми:
echo 15 > /proc/sys/vm/swappiness
Якщо ви віддаєте перевагу майже завжди зберігати програми в оперативній пам’яті, ви можете встановити це значення 1. Якщо ви встановите це на нуль, ядро взагалі не буде міняти місцями, якщо це абсолютно не потрібно, щоб уникнути OOM. Якщо у вас обмежена пам'ять і ви працюєте з великими файлами (наприклад, редагування HD-відео), можливо, було б доцільно встановити це значення близько 100.
У наш час (2017) я вважаю за краще взагалі не робити своп, якщо у вас достатньо оперативної пам’яті. Якщо не здійснювати заміну, зазвичай ви втратите 200-1000 МБ оперативної пам’яті на довго працюючих настільних машинах. Я готовий пожертвувати таким чином, щоб уникнути затримки найгіршого випадку (заміни коду програми, коли оперативна пам'ять заповнена). На практиці це означає, що я віддаю перевагу OOM Killer перед свопом. Якщо ви дозволяєте / потребуєте заміни, ви можете також збільшити /proc/sys/vm/watermark_scale_factor, щоб уникнути затримок. Я б запропонував значення між 100 і 500. Ви можете розглянути цей параметр як торгівлю процесором для зниження затримки своп. За замовчуванням - 10, а максимально можливе - 1000. Більше значення повинно (відповідно до документації на ядро ) призводити до більшого використання процесора для kswapdпроцесів та зниження загальної затримки заміни.
Далі, скажіть ядро, щоб він віддав перевагу збереженню ієрархії каталогів у пам’яті над вмістом файлу, якщо якась оперативна пам’ять потребує звільнення (знову ж таки, якщо все входить в оперативну пам’ять, цей параметр нічого не робить):
echo 10 > /proc/sys/vm/vfs_cache_pressure
Налаштування vfs_cache_pressureмале значення має сенс, оскільки в більшості випадків ядро має знати структуру каталогів, перш ніж воно зможе використовувати вміст файлу з кешу, а занадто рано промивання кешу каталогу зробить кеш файлу поруч з непридатним. Якщо ви маєте багато невеликих файлів (у моїй системі є близько 150 Кб 10-мегапіксельних фотографій і вважається системою "безліч малих файлів") до 1-го рівня. Ніколи не встановлюйте його на нуль, або структура каталогу завжди зберігається в пам'яті, навіть якщо в системі не вистачає пам'яті. Встановити велике значення доцільно, лише якщо у вас є лише кілька великих файлів, які постійно перечитуються (знову ж таки, редагування HD відео без достатньої кількості оперативної пам’яті було б прикладом). Офіційна документація на ядро говорить, що "
Виняток: якщо у вас справді величезна кількість файлів і каталогів, і ви рідко торкаєтесь / читаєте / перелічуєте всі файли, налаштування яких vfs_cache_pressureперевищує 100, може бути розумним. Це стосується лише якщо у вас недостатньо оперативної пам’яті та не вдається зберегти всю структуру каталогів в оперативній пам’яті та все ще маєте достатню кількість оперативної пам’яті для нормального кешування файлів та процесів (наприклад, загальнофірмовий файловий сервер з великою кількістю архівного вмісту). Якщо ви вважаєте, що вам потрібно збільшити vfs_cache_pressureпонад 100, ви працюєте без достатньої оперативної пам’яті. Збільшення vfs_cache_pressureможе допомогти, але єдине справжнє виправлення - отримати більше оперативної пам’яті. Встановивши vfs_cache_pressureвисоку кількість жертв середньої продуктивності за стабільнішу ефективність в цілому (тобто ви можете уникнути дійсно поганої поведінки в гіршому випадку, але доведеться мати справу з гіршими загальними показниками).
Нарешті, скажіть ядро використовувати до 99% оперативної пам’яті як кеш для запису, і доручіть ядру використовувати до 50% оперативної пам’яті, перш ніж уповільнити процес написання (за замовчуванням dirty_background_ratioє 10). Попередження: Я особисто цього не зробив би, але ви стверджували, що маєте достатню кількість оперативної пам’яті і готові втратити дані.
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
І скажіть, що затримка запису на 1 год нормальна, щоб навіть почати писати речі на диск (знову ж, я б цього не робив):
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
Якщо ви поставите все це до /etc/rc.localі включите наступне в кінці, все буде в кеші якнайшвидше після завантаження (зробіть це лише в тому випадку, якщо ваша файлова система дійсно вписується в ОЗУ):
(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&
Або трохи простіша альтернатива, яка може працювати краще (кеш-пам’яті /homeта /usr, робити це лише у тому випадку, якщо ваш /homeі /usrсправді вписується в оперативну пам’ять):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&