Кажется, я не могу найти много экспертной информации об использовании серверов баз данных на SSD в отношении обрезки. Я знаю, что могу включить сброс RAID и LVM и использовать fstrim / cron или discard параметр монтирования для ext4 (который зависит от поведения записи), но, например, файлы данных MySQL сжимаются только с optimize table и тогда вам нужно иметь inno_db_file_per_table включен. На столах по несколько 100 ГБ, optimize table займет некоторое время, и это нелегко.
Правильно ли обрабатывают сбросы базы данных, в частности MySQL? Могут ли они даже отправить удаление файлов, которые, по мнению файловой системы, все еще содержат данные?
Я знаю, что без обрезки ваша производительность может действительно упасть через несколько месяцев и дать вам усиление записи, поэтому я и опасаюсь.
Для производительности SSD хорошее резюме и несколько отличных ссылок можно найти на эта серия сообщений в блогах.
Общие рекомендации из главы 6 могут быть актуальны для вас, поскольку я сомневаюсь, что TRIM очень поможет вам с базами данных. Я думаю, что база данных обычно перезаписывает блоки, а не удаляет такое количество файлов. Хороший общий совет по настройке производительности:
26. Избыточное резервирование полезно для выравнивания износа и повышения производительности.
Диск может быть избыточно выделен, просто отформатировав его до размера логического раздела, меньшего, чем максимальная физическая емкость. Оставшееся пространство, невидимое для пользователя, по-прежнему будет видно и использоваться контроллером SSD. Избыточное выделение ресурсов помогает механизмам выравнивания износа справляться с ограниченным сроком службы ячеек NAND-flash. Для рабочих нагрузок, в которых операции записи не такие большие, достаточно 10–15% избыточного выделения ресурсов. Для рабочих нагрузок с постоянной случайной записью сохранение до 25% избыточного выделения ресурсов повысит производительность. Избыточное выделение ресурсов будет действовать как буфер блоков NAND-flash, помогая процессу сборки мусора поглощать пики записи.
Если вы не используете самые дешевые твердотельные накопители на потребительском рынке, а с базами данных объемом более 100 ГБ вы, вероятно, этого не сделаете, это вряд ли станет проблемой для вас.
Запись усиления
Вам придется писать очень много, чтобы хотя бы приблизиться к ограничению эффективного срока службы современных (например, изготовленных за последние 12 месяцев) SSD. Отрасль в целом сумела повысить долговечность ячеек в достаточной степени, выяснить, сколько свободной площади необходимо для компенсации неисправных ячеек, и провести прямую оптимизацию микропрограмм, благодаря которой вы сможете продлить срок службы не менее 3 лет с высокой производительностью даже на потребителе. -современное оборудование. Для старых SSD это было верно, но теперь это не так; в большинстве случаев это пережиток мифологии более древних времен.
Честно говоря, долговечность MLC все еще остается фактором при высоких нагрузках записи. А под высоким значением мы говорим об эквиваленте нескольких операций записи всего диска в день в течение многих лет. Если вы относитесь к этому классу производительности, вы, вероятно, больше не работаете на «потребительском» рынке.
Удары по производительности перепрограммирования клеток
Или то, что вы сказали, вам нужно TRIM / Discard. Это хорошо известный «дефект» твердотельных накопителей типа MLC. Однако доработки прошивки за эти годы позволили снизить большую часть снижения производительности при записи на SSD этого типа. Диски SLC по-прежнему доступны, и благодаря настройкам, позволяющим продлить срок службы дисков MLC, большой причины для использования SLC больше нет, поэтому сейчас они довольно редки. Но если вы отправляете на диск достаточно крошечных записей, чтобы продлить срок службы MLC, устройство SLC начинает иметь смысл.
Если вы выделяете достаточно неиспользуемого места на дисках БД, большинство прошивок SSD достаточно умен, чтобы заметить, что определенные блоки не распределены, и рассматривать их как дополнительную резервную область. При запуске фоновых процессов дефрагментации резервная область повторно инициализируется. Это сохранит производительность на высоком уровне. Так что отсутствие поддержки отбрасывания на уровне блоков в MySQL не имеет большого значения.