Чому по мірі заповнення SSD падає швидкість запису RAID

Ця проблема найбільш актуальна для апаратних RAID або firmware RAID (таких як Intel RST RAID 1/10/5/6) з непромышленными SSD.

Особливість SSD

SSD пишуть і читають дані сторінками, можна записати тільки на очищені сторінки, а очистити сторінки можна лише великими блоками. Наприклад, у диска розмір сторінки 8 КБ, в блоці знаходиться 128 сторінок, таким чином, розмір блоку — 1024 КБ (тут і далі, якщо не вказано іншого, КБ і МБ двійкові).

Наприклад, якщо змінити 40 КБ в одному файлі, то на фізичному рівні це буде виглядати так:



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

Щоб приховати фізичну реалізацію, диск підтримує карту відповідності логічних і фізичних номерів сторінок (Flash Translation Layer).

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

Щоб вирішити цю проблему, була додана команда ATA TRIM wiki). Операційна система посилає її диску із зазначенням секторів, які можуть бути очищені. Аналоги цієї команди — SCSI UNMAP і CF ERASE. На жаль, в деяких випадках немає можливості послати її диску:
— якщо диск знаходиться в RAID з апаратним контролером (LSI, Adaptec тощо),
— якщо диски знаходиться в firmware-RAID, зокрема, Intel RST RAID 1/10/5/6,
— якщо диск підключений по USB.

Якщо в результаті тестування з'ясовується, що диск не отримує команду TRIM, то незабаром для запису може залишитися зовсім мало вільних сторінок. Але вони будуть: кожен диск містить деяку зарезервовану область, яка служить як запас вільних сторінок і запас блоків на заміну повністю зношеним. Щоб дізнатися розмір цієї області потрібно подивитися, який фізичний обсяг пам'яті встановлено на диску і скільки LBA зазначено в документації.

Наприклад, Samsung SSD 840 Pro 512 GB має 512 ГБ пам'яті, при цьому доступно 1000215216 LBA секторів. Резерв становить: 512 × 1024 × 1024 × 1024 — 1000215216 × 512 = 35 ГБ або 6,85 %. Доступна ємність диска при цьому становить(512 — 35) × 1024 × 1024 × 1024 = 512 × 10^9 = 512 ГБ, вже десяткових. Samsung SSD 850 Pro 128 ГБ має на борту 129 ГБ, користувачеві доступно 128 ГБ десяткових, резерв — 7,6 %.

Отже, якщо ми заповнимо весь диск, потім видалимо всі файли, то без підтримки TRIM диск зможе писати тільки на якусь частину від 6,85 % обсягу диска. Частина, тому що цей резервний об'єм буде частково складатися з не повністю порожніх блоків з-за фрагментації. Наявність цій області дозволяє хоч якось продовжувати перезапис файлів на диску.

Приклад гіршій ситуації: писати нікуди, хоча обсяг зайнятих сторінок не перевищує доступний користувачеві без резерву.



У цьому разі одночасно з записом працює збирач сміття, який буде читати блок в оперативну пам'ять, прати блок на диску (довга операція, стирання займає 3000 мкс в порівнянні з 900 мкс запису в порожню сторінку) і записувати блок з оперативної пам'яті. Затримка відбувається також через зростання Write Amplification — на одну логічну операцію запису припадає 5-10 фізичних операцій запису.

Тому чим більше у диску є вільного місця для маневрів, тим вище швидкість запису. Збирач сміття на тлі займається не тільки очищенням і дефрагментацией блоків, але і рівномірним розподілом циклів запису/очищення (P/E) блокам, щоб вони зношувалися однаково.

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

Промислові диски часто мають 50% і більше резервної області, тому для них відсутність TRIM не критично. Інші диски найчастіше взагалі не мають явно заявленої резервної області, або вона недостатня. Тести показують, що хороший ефект має обсяг over-provisioning 25-29 % від загального обсягу фізичної пам'яті (включаючи резервну область). Тому якщо диск недостатній обсяг резервної області, то потрібно зробити over-provisioning самостійно.

Є три способи:
— розмітити диск таким чином, щоб залишити деяку частину нерозмічену області,
— використовувати команду ATA для створення Host protected area howto),
— налаштувати RAID контролер, щоб він використав тільки частину обсягу диска.

Перш ніж виділити вільну область, потрібно дати знати диска, що ця область нічим не зайнята, одним з двох способів:
— підключити диск з іншого контролера і надіслати команду ATA TRIM (або за допомогою O&O Defrag — є cli інтерфейс Windows 8 вбудований оптимізатор дисків або Anvil's Storage Utilities),
— зробити повне очищення таблиці FTL, пославши команду ATA Secure Erase.

Є версія, що також можна змусити диск зрозуміти, що блоки не використовуються, якщо туди записати 0x00 або 0x01 (так званий метод «Tony TRIM»). Можливо, для якихось контролерів це працює, але мої тести не показали змін.

На практиці

У мене є два диска Samsung SSD 540 Pro 512 GB Intel RST RAID 1, на яких встановлена Windows 8.1. Після року роботи я виміряв продуктивність і був неприємно здивований. Після перевірки TRIM я побачив, що він не працює. Я вирішив створити неразмеченный розділ диска для over-provisioning.

1. За допомогою Acronis Backup я зняв образ диска. Також зберіг таблицю розділів (важливо мати перший сектор, останній сектор, GPT тип розділу, GPT унікальний ідентифікатор, ім'я розділу).

2. Перезавантажився в BIOS і зробив SSD Secure Erase. Якщо цього пункту немає в BIOS, то можна виконати команду за допомогою hdparam або тут і тут, є під Windows), HDDErase або HDAT2.

3. Зібрав RAID 1 на двох дисках.

Тут потрібно зробити важливе зауваження: при ініціалізації масиву RAID-контролер зчитує кожен сектор з одного диска і записує його на другий. Теоретично це повинно перешкодити усієї нашої затії, і на одному диску не буде over-provisioning. Але тести показали, що цей метод чому-то працює. У мене цього немає пояснень.

4. Завантажився з LiveCD і за допомогою GPT fdisk створив потрібну таблицю розділів: останній розділ на 104 ГБ менше, ніж раніше. Розділи потрібно вирівнювати (partition align) за розміром сторінки диска, а не за розміром блоку.

5. Відновив з резервної копії кожен розділ.

Після цього я повністю заповнив диск і запустив тести. Це має показати найгірший випадок. Кеш Windows включений, регулярна запис кеша вимкнена, Inter RST write-back вимкнений, всі тести використовують область диска фіксованого розміру в 40 ГБ. Тестувати диски непросто, оскільки показники можуть змінюватися у часі. Нижче зведені показники усталеного стану.

Я порівняю три стани:
— Один диск без RAID, повністю заповнений, стандартна прихована резервна область 6,58 %.
— Один диск без RAID, після запуску на ньому TRIM вільного місця.
— Два диска в RAID 1, повністю заповнені, стандартна прихована резервна область 6,58 %.
— Два диска в RAID 1, повністю заповнені, over-provisioning 27,24 % (включаючи приховану резервну область).


Латентність і стандартне відхилення
Таблиця

Аналіз результатів:
— читання з RAID 1 виявляється швидше, ніж з одного диска, незважаючи на те, що у нас всього лише firmware RAID.
— запис тим швидше, чим більше нерозподіленого простору: на першому місці TRIM, на другому — наш саморобний over-provisioning.

Сталий стан не завжди досягається швидко. Подивимося тест останньої конфігурації (over-provisioning 27,24 %) в динаміці і побачимо найгірший випадок:





Цікавий процес йде перші 400 секунд, після чого зростає продуктивність і стабілізується. Я думаю, паралельно із записом працює збирач сміття, який дефрагментує блоки і готує їх для запису. Така поведінка спостерігається не кожен раз, а час від часу. Видно, що послідовна запис просідає до 70 МБ/з, випадковий запис — до 18000 IOPS. Ці показники все одно в два рази краще, ніж без over-технічного 32 МБ/с і 7139 IOPS відповідно). Щоб переконатися, що сталий стан насправді має таку високу продуктивність, я також виконав тест протягом 30 хвилин, при цьому було записано на диск 490 ГБ з середнім 69721 IOPS.

Можна порівняти наші результати із колегами та вибрати оптимальний розмір over-provisioning:

Коротко

— Якщо диск отримує ATA TRIM від ОС, то турбуватися не про що, досить залишати частина місця на диску вільним.
— Якщо використовуються дорогі промислові диски, то перевірте об'єм вбудованої резервної області, якщо він достатній, то проблем із записом не буде.
— В інших випадках потрібно залишити не розмічену область, чим більше її розміри, тим менше буде стандартне відхилення латентності запису.
— Іноді збирач сміття не встигає підготувати чисті блоки і швидкість запису може просісти і бути непостійною.

Ще почитати.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.