SSD в серверной: два Intel X25-E под журналы SQL Server и что из этого вышло

Когда Intel объявила X25-E Extreme, мы поставили его в очередь «интересно, но не сейчас» - корпоративный SSD со стоимостью порядка тысячи долларов за 32 ГБ это не то, что берёшь не подумав. Но один из клиентов давно жаловался на задержки записи в SQL Server, мы перебрали стандартные объяснения и уткнулись в один вывод: узкое место - именно журналы транзакций на SAS. Решили попробовать.

Взяли два X25-E, поставили под журналы транзакций. Вот что получилось.

Почему именно журналы

SQL Server пишет в журнал транзакций последовательно и синхронно - каждая транзакция ждёт подтверждения записи перед тем как вернуть управление приложению. Это значит, что latency записи журнала напрямую превращается в latency транзакции. Никакой RAID-кеш и никакая оптимизация запросов не уберут это ожидание.

На SAS 15K у клиента среднее время записи в журнал болталось в районе 7-9 мс. Для некоторых операций - пакетных вставок, транзакций с несколькими таблицами - это складывалось в очень неприятную картину. OLTP-нагрузка, двести-триста пользователей в час пик, и база начинает заметно тормозить именно на записи.

Данные и tempdb на SAS мы не трогали - там узкого места нет, там IOPS и throughput, с чем обычные диски справляются нормально. Журналы - отдельный том, идеально подходит под точечный эксперимент.

Что показали первые дни

Разница оказалась настолько резкой, что мы перепроверяли измерения несколько раз. Среднее время записи в журнал на X25-E - около 0.1 мс, иногда чуть больше, но в единицы долей миллисекунды. По сравнению с 8 мс на SAS - это другой порядок величины, не проценты.

Практический эффект для пользователей: пакетные операции, которые раньше уходили на несколько секунд, теперь возвращаются мгновенно. Время отклика базы в час пик выровнялось. Клиент заметил без всяких подсказок - просто написал, что «база стала быстрее», хотя мы ни слова не сказали, что что-то меняли.

Несколько конкретных наблюдений за первую неделю:

Последовательная запись - сильная сторона. X25-E на журналах работает именно там, где ему хорошо: последовательные записи небольшими блоками, синхронное подтверждение. Это именно профиль журнала транзакций, не случайный IOPS.

Температура и физика. Диски не греются, не шумят, потребляют существенно меньше. В серверной это не первостепенно, но приятно. Больший сюрприз - никакого «прогрева»: SSD работает одинаково с первой минуты.

RAID на SSD - отдельный вопрос. Мы поставили два диска в зеркало (RAID 1) через аппаратный контроллер. Теоретически это правильно - отказоустойчивость. Практически открытый вопрос: как контроллер будет обращаться с выравниванием записи и сборкой мусора на SSD. Логика оптимизации у контроллера заточена под вращающиеся диски, у SSD другие характеристики деградации. Наблюдаем.

Где применять, а где нет: вопрос цены

Вот тут и начинается расчёт. Два X25-E 32 ГБ - это несколько тысяч долларов за 64 ГБ полезной ёмкости. За те же деньги можно взять стойку SAS-дисков суммарным объёмом в терабайты. Применять X25-E везде подряд - выбросить деньги в форточку.

Логика применения, которую мы для себя формулируем:

Журналы транзакций OLTP - прямое попадание. Объём небольшой, профиль записи идеальный для SSD, latency критична для конечного пользователя. Именно здесь цена за ГБ оправдана, потому что ёмкость нужна маленькая, а эффект - максимальный.

tempdb на активных базах - следующий кандидат, но с оговорками. tempdb активно читает и пишет случайными блоками, SSD здесь тоже быстрее SAS. Но объём tempdb может быть непредсказуемым, и если база начнёт активно использовать сортировки и хеш-джойны - потребуется больше места, чем рассчитывали.

Данные - не вписывается в бюджет. Объёмы баз данных у клиентов - десятки и сотни гигабайт, иногда больше. Класть их на SSD по нынешней цене за ГБ не считается даже на калькуляторе.

Общее файловое хранилище, архивы, бэкапы - точно нет. Там важна ёмкость, а не скорость.

Открытые вопросы

X25-E использует MLC-флеш с серверной прошивкой и более агрессивным резервированием ёмкости под wear leveling. Intel заявляет ресурс существенно выше, чем у потребительских SSD. Верим, но проверить не на чем - слишком мало времени в продуктиве.

Износ флеш-ячеек при интенсивной записи в журнал - это вопрос, который надо держать в голове. Журнал транзакций перезаписывается постоянно, это одна из самых write-intensive нагрузок. Насколько ресурса хватит на несколько лет - посмотрим. Пока мониторим через SMART и фирменные утилиты.

Ещё один открытый вопрос - поведение при отключении питания. У корпоративных SSD должны быть конденсаторы под защиту кеша записи, у X25-E с этим всё в порядке по документации. Но хотелось бы проверить это на практике, а не брать на веру.

Пока вывод промежуточный: для точечного применения под журналы транзакций Intel X25-E работает именно так, как обещают цифры, и эффект для пользователей ощутимый. Расчёт «куда именно ставить» - это не вопрос вкуса, а чистая арифметика: ёмкость, профиль нагрузки, цена. Если на вашем объекте SQL Server тормозит на записи, а журналы живут на SAS вместе с данными - это первое, что стоит разобрать в рамках managed-сопровождения.