Почему не нужен TRIM в серверах
Для начала стоит разобраться с тем, как работает SSD, что такое сборка мусора, как работает TRIM и главное — почему он не нужен в серверах.
SSD отличается от HDD не только ограниченным ресурсом ячеек. Есть еще множество архитектурных особенностей.
Размеры секторов
Стандартный размер сектора для большинства блочных устройств (жестких дисков и систем хранения данных) равен 512 байт (на некоторых SAS/SCSI дисках возможны 520/528 байт для дополнительного контроля целостности данных). Последние несколько индустрия пытается перейти на секторы 4096 байт (4 КиБ), т.н. Advanced Format. Продвигается процесс медленно, все пока что остановилось на 512e, т.е. дисках с 4K-секторами внутри, но с эмуляцией 512 байт секторов для хоста. На дисках 512e могут возникать проблемы с производительностью: при необходимости записать блок данных размером меньше 4 КиБ контроллеру диска приходится считывать сектор, менять в нем данные и только потом записывать обратно. Для SSD ситуация с записью небольших блоков еще сложнее:
Контроллер SSD по-прежнему вынужден прикидываться блочным устройством с 512 байт сектором. Но внутри все сложнее: ячейки объединены в страницы размером, как правило, 4-8 КиБ, т.е. это минимально доступный для чтения или записи объем. Записать данные в ячейку/страницу просто так нельзя, для этого нужно предварительно выполнить операцию стирания, а стереть можно только целый блок, состоящий из нескольких десятков (например, 64 или 128, в зависимости от архитектуры SSD) страниц, т.е. минимально доступный для стирания блок может оказаться размером, например, в 512 КиБ.
Write amplification (усиление записи)
Данный термин означает соотношение между объемом данных, который фактически приходится записывать на флеш-память, и объемом, который пишет хост. Предположим, что у нас есть блок 512 КиБ с данными и нужно поменять небольшой фрагмент. Для модификации сектора в 512 байт контроллеру SSD приходится делать несколько операций (ситуация напоминает write penalty для RAID-5/6):
- прочитать весь блок в буфер
- модифицировать содержимое буфера
- стереть весь блок
- записать новое содержимое буфера
Т.е. для размера транзакции в 512 байт на SSD с размером блока страниц в 512 КиБ получаем write amplification = 1024 раза. Это не самым лучшим образом сказывается а) на производительности и б) ресурсе, который по-прежнему составляет несколько тысяч циклов перезаписи для MLC SSD.
Copy on write
Проблема усиления записи имеет простое решение: нужно стараться записывать данные в уже предварительно стертые блоки. На помощь приходит классический алгоритм copy-on-write, разновидности которого используются для оптимизации записи в RAID-DP у Netapp или в ZFS (только слоем выше — на уровне файловой системы).
Суть алгоритм copy-on-write заключается в записи в «выгодные» участки носителя, т.е. в случае SSD — на чистые (стертые) блоки. В нижеприведенном примере модифицируется содержимое страницы «B». Вместо чтения/стирания/записи всего большого блока достаточно лишь прочитать содержимое страницы, модифицировать ее и записать в другое место. При этом необходимо поменять указатель, чтобы те же LBA указывали на новое физическое место размещения данных.
В качестве дополнительного средства борьбы с write amplification большинство современных контроллеров SSD используют сжатие данных.
Где взять чистые блоки?
На новом SSD все блоки являются чистыми и готовыми к записи. Дальше есть резервная область, которая на самом деле, используется всегда, так как помимо оптимизации записи необходимо обеспечить еще и равномерность износа ячеек SSD.
TRIM
Как быть, если после непрерывной записи чистых блоков уже не осталось? Для можно каким-либо образом узнать, где на SSD находятся пользовательские данные, а где размещены невалидные данные, оставшиеся после удаления файлов. Собственно, этим и занимается TRIM. SSD, как и любое другое блочное устройство, ничего не знает, о том, какие именно данные на нем хранятся. ОС может взаимодействовать как со слоем файловой системы, так и с блочным устройством, т.е. после удаления файла ОС передает на SSD вместе с командой TRIM (или UNMAP для SCSI) список LBA, по которым находились удаленные данные. SSD получает в распоряжение блоки с невалидными данными, и эти блоки можно в дальнейшем использовать для записи.
Background garbage collection (фоновая сборка мусора)
Второй очевидный способ обнаружения невалидных данных — повторные запросы на запись от хоста по тем же LBA. Для хоста это выглядит, как перезапись одних и тех же секторов, но SSD все время старается писать в разные блоки. В вышеприведенной иллюстрации работы copy-on-write актуальные данные содержатся в новой странице «B'», после чего в исходной странице остаются невалидные данные.
Области с невалидными данными могут быть сильно фрагментированы, т.е. содержать ячейки с нужными данными. Остается последний шаг — дефрагментировать эти области, получив набор целых свободных блоков и выполнить их стирание.
Собственно, за все это и отвечает сборка мусора. «Правильные» SSD, рассчитанные на интенсивную запись, имеют достаточный over-provisiong (резервную область) в качестве «пространства для маневра» и эффективный контроллер с достаточным объемом кэша (разумеется, защищенного конденсаторами) для размещения метаданных и буферизации чтения/записи. Если контроллер не успевает быстро подготовить место для быстрой записи, то это неминуемо отразится на производительности, будет периодический рост задержек в несколько раз относительно среднего значения, как на данной картинке с www.storagereview.com:
TRIM и реальность
Для работы TRIM помимо выполнения множества условий (поддержка со стороны ОС и файловой системы) необходимо разобраться с другими слоями абстракции, например, RAID. Пересчитать адреса пришедшие на с TRIM на контроллер от хоста и раскидать их по отдельным дискам теоретически возможно, но никто (ни LSI, ниAdaptec by PMC) не торопится с реализацией. Причина проста — за пределами домашних систем или рабочих станций такая простая вещь, как удаление файла встречается крайне редко. В серверах, как правило, встречаются совершенно другие нагрузки, к которым TRIM не может иметь никакого отношения:
- Виртуализация. На физическом диске или томе RAID-контроллера лежит одна файловая система (VMFS/NTFS/XFS), а на ней — виртуальный диск в виде файла (который никуда не удаляется и даже не меняется в размере, если диск не тонкий), а внутри виртуального диска — другая ФС. Как, от кого и кому передавать TRIM в такой ситуации — совершенно непонятно.
- Предоставление блочного доступа. Это добавляет несколько уровней абстракции. Том->Раздел (или ФС + файл)->Таргет->Файловая система
- Файловый доступ. В организациях, как правило, никто не удаляет регулярно большое количество файлов. Такой сценарий встречается разве что при хранении временного медиа-контента, например, при рендеринге или перекодировании видео, а SSD тут совершенно не нужны. Файл-сервер обычно используется для долговременного хранения информации.
- Базы данных. Файл, который, опять-таки не удаляется, а лишь модифицируется и растет.
Заключение
Используйте совместимые с вашим контроллером SSD, выбирайте их с учетом ожидаемой нагрузки на запись и не волнуйтесь о TRIM.
Фоновая сборка мусора
При фоновой сборке мусора сборка эфемерных поколений (0 и 1) выполняется по мере надобности, в ходе выполнения сборки поколения 2. Фоновая сборка мусора выполняется в одном или нескольких выделенных потоках в зависимости от того, является ли это рабочая станция или сборка мусора сервера, и применяется только к коллекциям поколения 2.
Фоновая сборка мусора включена по умолчанию. Ее можно включить или отключить с помощью параметра конфигурации gcConcurrent в приложениях .NET Framework или параметра System.GC.Concurrent в приложениях .NET Core и .NET 5 и более поздних версий.
Фоновая сборка мусора заменяет параллельную сборку мусора и доступна в .NET Framework 4 и более поздних версиях. В .NET Framework 4 она поддерживается только для сборки мусора на рабочих станциях. Начиная с .NET Framework 4.5 фоновая сборка мусора доступна для сборки мусора как на рабочих станциях, так и на серверах
Сборка для эфемерных поколений во время фоновой сборки мусора называется высокоприоритетной сборкой мусора. Во время выполнения высокоприоритетных сборок мусора все управляемые потоки приостанавливаются.
Если выполняется фоновая сборка мусора и в поколении 0 размещено достаточное количество объектов, среда CLR выполняет высокоприоритетную сборку мусора для поколения 0 или поколения 1. Выделенный поток фоновой сборки мусора проверяет в частых точках, безопасных для сбора мусора, чтобы определить, не появился ли запрос выполнения высокоприоритетной сборки мусора. В этом случае фоновая сборка мусора приостанавливается, чтобы позволить выполниться высокоприоритетной сборке мусора. После выполнения высокоприоритетной сборки мусора работа выделенного потока фоновой сборки мусора и пользовательских потоков возобновляется.
Фоновая сборка мусора удаляет ограничения на распределение, наложенные параллельной сборкой мусора, так как эфемерные сборки мусора могут выполняться во время фоновой сборки мусора. Фоновая сборка мусора может удалить неиспользуемые объекты в эфемерных поколениях. Она также при необходимости может увеличить кучу во время сборки мусора поколения 1.
Фоновая сборка мусора на рабочих станциях и серверах
Начиная с .NET Framework 4.5 фоновая сборка мусора стала доступна для серверной сборки мусора. Это режим по умолчанию для сборки мусора сервера.
Этот режим функционирует аналогично фоновой сборке мусора рабочей станции, но с некоторыми отличиями.
- Для фоновой сборки мусора рабочей станции используется один выделенной поток фоновой сборки мусора, тогда как для фоновой серверной сборки мусора используется несколько потоков. Как правило, имеется по одному выделенному потоку для каждого логического процессора.
- В отличие от потока фоновой сборки мусора рабочей станции у потоков фоновый сборки мусора сервера время ожидания не истекает.
На следующем рисунке показана фоновая сборка мусора рабочей станции в отдельном выделенном потоке:
На следующем рисунке показана фоновая сборка мусора сервера в отдельном выделенном потоке:
Параллельная сборка мусора
Этот раздел касается:
- .NET Framework 3.5 и более ранних версий в части, относящейся к сборке мусора рабочей станции;
- .NET Framework 4 и более ранних версий в части, относящейся к серверной сборке мусора.
В более поздних версиях параллельная сборка мусора заменена на фоновую.
При сборке мусора рабочей станции или серверной сборке мусора можно включить параллельную сборку мусора, что позволит потокам работать параллельно с выделенным потоком, выполняющим сборку мусора, в течение большей части продолжительности сборки. Этот вариант влияет только на сборки мусора для поколения 2, сборки для поколений 0 и 1 всегда выполняются непараллельно, так как они заканчиваются быстро.
Параллельная сборка мусора позволяет интерактивным приложениям лучше реагировать, минимизируя паузы для сборки. В течение большей части времени выполнения потока параллельной сборки мусора управляемые потоки могут продолжить выполнение. Это приведет к сокращению пауз во время выполнения сборки мусора.
Параллельная сборка мусора выполняется в выделенном потоке. По умолчанию среда CLR выполняет сборку мусора рабочей станции с выключенной параллельной сборкой мусора, как на компьютерах с одним процессором, так и с несколькими.
На следующем рисунке показана параллельная сборка мусора на отдельном выделенном потоке.
См. также
- Сборка мусора рабочей станции и сборка мусора сервера
- Параметры конфигурации среды выполнения для сборки мусора
Совместная работа с нами на GitHub
Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.
Background Garbage Collection
Процесс очистки памяти SSD накопителей от мусорной информации. При удалении файлов в операционной системе удаляется только информация о местоположении самого файла, сам же файл остается. Это приводит к снижению производительности SSD. Background Garbage Collection в фоновом режиме, то есть во время отсутствия запросов к диску от операционной системы, автоматически удаляет сами файлы. Для повышения эффективности работы Background Garbage Collection используются команды TRIM.
SSD, fstrim и mount -o discard
/home: ФС ext4, смонтирована с опциями relatime,discard,commit=30 .
sudo fstrim -v /home /home: 44191338496 bytes were trimmed То есть около 40Гб. В прошлый раз, когда я запускал fstrim, оно тоже показало ненулевое значение, но тогда я это списал на то, что при создании и первоначальном использовании /home оно монтировалось без discard. Сейчас такая отмазка уже не катит.
discard не работает или я чего-то не понимаю?
selivan ★★★
07.03.14 19:12:49 MSK
Система не помнит, какие блоки (из не занятых данными) ранее были подвергнуты TRIM’у.
intelfx ★★★★★
( 07.03.14 19:21:39 MSK )
Ответ на: комментарий от intelfx 07.03.14 19:21:39 MSK
selivan ★★★
( 08.03.14 03:56:01 MSK ) автор топика
Ответ на: комментарий от selivan 08.03.14 03:56:01 MSK
К слову, видимо, ext234 всё-таки кэширует это в памяти, поэтому второй раз подряд fstrim работать не будет (в смысле, скажет «0 bytes were trimmed»). Но после перезагрузки стейт предсказуемо теряется.
intelfx ★★★★★
( 08.03.14 11:44:11 MSK )
26 ноября 2014 г.
Ответ на: комментарий от intelfx 08.03.14 11:44:11 MSK
Но после перезагрузки стейт предсказуемо теряется.
Так если работа с устройством ведётся, то, спустя непродолжительное время, там будут новые неочищенные блоки. Может, это не ФС кэширует, а устройство исполняет команты не мгновенно, и, получив задание от fstrim, ещё долго работает ? Никто в код не смотрел ? Действительно, интересно.
Кстати, ещё интересно получить стастистику по неочищенным блокам, если таковое, вообще, возможно.
AS ★★★★★
( 26.11.14 15:38:54 MSK )
Ответ на: комментарий от AS 26.11.14 15:38:54 MSK
спустя непродолжительное время, там будут новые неочищенные блоки
Так и есть. Но вновь появляющиеся свободные блоки обрабатываются в реалтайме.
Может, это не ФС кэширует, а устройство исполняет команты не мгновенно, и, получив задание от fstrim, ещё долго работает ?
И fstrim, и сама команда TRIM выполняются синхронно. Даже если fstrim выполнялся бы асинхронно, на время фактического discard’а система вставала бы колом.
Там (в ext234) совершенно точно два битмапа. Я смотрел в код, когда писал поддержку discard для reiser4.
intelfx ★★★★★
( 26.11.14 15:45:23 MSK )
Последнее исправление: intelfx 26.11.14 15:45:59 MSK (всего исправлений: 2)
Ответ на: комментарий от intelfx 26.11.14 15:45:23 MSK
Так и есть. Но вновь появляющиеся свободные блоки обрабатываются в реалтайме.
То есть, fstrim вообще больше до перезагрузки не запустится ? Ну или отмонтирования раздела и монтирования обратно.
И fstrim, и сама команда TRIM выполняются синхронно. Даже если fstrim выполнялся
бы асинхронно, на время фактического discard’а система вставала бы колом.
Почему ? Такая же операция, как запись. Я что-то думал, что смысл trim в том, чтобы успевать готовить накопитель к записи при маленьком потоке данных, чтобы он был готов быстро отработать при большом без затрат времени на стирание. А если стирать синхронно, то это же тоже замедление, только не записи, а удаления. Так как-то не интересно.
Вообще, возник какой-то непонятный косяк. SSD-шка долго работала (несколько месяцев) с примерно постоянным потоком на запись. ext4, в опциях discard изначально. Некоторое время назад сильно взлетел i/o wait. Идёт от приложения, которое пишет на SSD. Первая посетившая мысль — что trim работает медленнее потока, и, наконец-то, закончились очищенные блоки. Хотя, пока, не очень подтверждается: пятиминутная остановка приложения сильно ситуацию не спасает, i/o wait взлетает почти сразу после запуска.
Если fstrim работает синхронно с реальной очисткой, то он что-то больно быстро это делает: 40Гб пробегает минуты за три. Сильно маленькая задержка на стирание одного блока, столько и при записи не жаль: 17 микросекунд на один 4K блок получилось. Ну и ситуация после fstrim не исправилась.
AS ★★★★★
( 26.11.14 16:23:48 MSK )
Ответ на: комментарий от AS 26.11.14 16:23:48 MSK
То есть, fstrim вообще больше до перезагрузки не запустится ?
Запустится, но ничего (или почти ничего) не будет делать. Есть случаи, в которых realtime discard не срабатывает; это зависит от используемых в ФС алгоритмов.
Почему ? Такая же операция, как запись.
Однако, до какой-то там ревизии SATA эта команда должна исполняться при пустой очереди («Trim has been defined as a non-queued command by the T13 subcommittee», https://en.wikipedia.org/wiki/Trim_(computing)#Shortcomings).
Я что-то думал, что смысл trim в том
Смысл TRIM в том, чтобы балансировщик нагрузки (который время от времени переназначает логические сектора на разные физические) знал, какие сектора пустые.
Если fstrim работает синхронно с реальной очисткой, то он что-то больно быстро это делает: 40Гб пробегает минуты за три.
Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная очистка всего диска занимает секунд десять.
intelfx ★★★★★
( 26.11.14 16:37:25 MSK )
Ответ на: комментарий от intelfx 26.11.14 16:37:25 MSK
Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная очистка всего диска занимает секунд десять.
А ты уверен, что у тебя что-то там вообще очищается?
anonymous
( 26.11.14 20:28:12 MSK )
Ответ на: комментарий от anonymous 26.11.14 20:28:12 MSK
Уверен, мамой клянусь hdparm —read-sector соврать не даст.
intelfx ★★★★★
( 26.11.14 20:34:46 MSK )
Ответ на: комментарий от intelfx 26.11.14 16:37:25 MSK
Смысл TRIM в том, чтобы балансировщик нагрузки (который время от
времени переназначает логические сектора на разные физические) знал,
какие сектора пустые.
Всё же нет. Write amplification — второе следствие этой же проблемы. А первопричина — необходимость записи в пустую ячейу, которая должна быть предварительно очищена. Плюс термин «сборщик мусора» («garbage collection») обычно подразумевает асинхронную работу. Я как-то так полагал, что для SSD аналогично.
Some SSD controllers implement background garbage collection (BGC), sometimes called idle garbage collection or idle-time garbage collection (ITGC), where the controller uses idle time to consolidate blocks of flash memory before the host needs to write new data. This enables the performance of the device to remain high.
AS ★★★★★
( 28.11.14 20:27:44 MSK )
Ответ на: комментарий от intelfx 26.11.14 16:37:25 MSK
Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная
очистка всего диска занимает секунд десять.
Похоже, SSD-шка моя таки не выдержала полугодового издевательства с записью. Вообще, была надежда, что продержится больше года хотябы. Только непонятно, почему скорость упала, а не сама возможность записи пропала. Или оно так и происходит перед переходом в r/o ? В результате, как раз, исчерпания скрытого запаса ? Но в SMART ничего подозрительного нет вроде.
AS ★★★★★
( 01.12.14 14:14:02 MSK )
Ответ на: комментарий от AS 28.11.14 20:27:44 MSK
Всё же нет. Write amplification — второе следствие этой же проблемы. А первопричина — необходимость записи в пустую ячейу, которая должна быть предварительно очищена.
Я как-то не совсем представляю, что понимается под «консолидацией блоков».
Похоже, SSD-шка моя таки не выдержала полугодового издевательства с записью.
Странно, уже упомянутый Vertex 4 жил у меня около двух лет в достаточно агрессивном режиме (10 GiB в день — легко). И то, «жизнь прервалась» в результате кражи ноута, а не отказа диска. По его внутреннему смартовскому счётчику ресурса оставалось около 90%.