Изменения

Производительность Ceph

6196 байтов добавлено, 13:52, 23 октября 2018
Нет описания правки
То есть, под Ceph следует закупать '''только''' SSD с конденсаторами. Даже если рассматривать NVMe — NVMe без конденсаторов хуже, чем SATA с оными.
'''Не проверено''': И ещё один вариант — Intel Optane. Они Это тоже SSD, но они основаны вообще не на Flash памяти, то есть, (не NAND и не NOR), а вообще на другой технологии, называющейся 3D XPoint. Хз , как она работает, но заявляются 550000 iops при полном отсутствии необходимости в стирании блоков, кэше и конденсаторах. Но а) в применении к Ceph — нужно проверять проверять — не факт, что Ceph вообще сможет выжать из них их iops-ы б) вариант дорогой, раза в 3 дороже типичной SSD (1500$ за 960 гб, 500$ за 240 гб). == Краткий экскурс в устройство SSD и флеш-памяти == Особенность флеш-памяти (NAND/NOR) заключается в том, что пишется она мелкими блоками (обычно 512 байт), но перед тем, как писать — блок нужно стереть. А вот стирать она умеет только крупные блоки («erase unit»), размером обычно 2-4 мегабайта (и стирание довольно медленное по отношению к записи). Кроме того, каждый erase unit ограничен числом стираний. После (типичное значение) нескольких тысяч стираний он физически выходит из строя. В более дешёвых чипах и MLC, TLC лимит стираний меньше, в более дорогих и SLC — больше. Таким образом, при «тупом» подходе перезапись флеш-памяти, во-первых, была бы очень медленной, а во-вторых, она бы быстро выходила из строя. Но почему тогда SSD быстрые? А потому, что внутри SSD на самом деле есть очень мощный и умный контроллер (1-2 гигагерца, примерно как процессоры мобильников), и на нём выполняется нечто, что называется Flash Translation Layer — прошивка, которая переназначает каждый мелкий логический сектор в произвольное место диска. FTL всё время поддерживает некоторое количество свободных стёртых блоков, каждая случайная запись на самом деле идёт в новое место диска — в стёртую область, и поэтому запись быстрая. Одновременно FTL делает дефрагментацию свободного места и Wear Leveling (распределение износа), направляя запись и перемещая данные так, чтобы все блоки диска стирались примерно одинаковое количество раз. Отсюда же вытекает и проблема с энергонезависимостью и «power loss protection»-ом — карты отображения секторов — это метаданные, которые при сбросе кэша тоже нужно сбрасывать в постоянную память. Именно эти карты и вносят торможение в работу настольных SSD с fsync. === Бонус: USB-флешки === А почему тогда USB-флешки такие медленные? Случайная запись на флешку 512-байтными (или 4 Кб) блоками обычно идёт со скоростью 2-3 iops. А флеш-память там ровно та же, что в SSD — ну, может, более дешёвые вариации, но разница же не на порядки. Ответ кроется в том, что на флешках тоже есть FTL, но по сравнению с SSD-шным он маленький и глупый. У него малая вычислительная мощность и мало памяти. Из-за малого объёма RAM контроллеру флешки, в отличие от контроллера SSD, негде хранить полную таблицу сопоставления виртуальных и реальных секторов — поэтому отображаются не сектора, а крупные блоки по где-то мегабайту или больше, а при записи есть лимит на количество «открытых» блоков. Как это происходит: * Допустим, вы пишете в сектор X.* Контроллер отображает блок, которому принадлежит этот сектор, на реальный блок, и «открывает» его — выделяет пустой блок, запоминает, что он «дочерний» для открытого и записывает туда один изменённый вами сектор.* Таким макаром можно открыть максимум N разных блоков; число N обычно очень маленькое — от 3 до 6.* Дальше если вы пишете следующий сектор из уже открытого блока — он просто записывается в его дочерний блок (что быстро).* Если же следующий записываемый сектор принадлежит другому блоку — какой-то из открытых блоков приходится закрывать и «сливать» содержимое дочернего блока с оригинальным. Для копирования больших файлов на флешку с любой из стандартных файловых систем этого достаточно: один открытый блок — данные, второй — метаданные записываемого файла. Запись последовательная, всё быстро. А вот при случайной записи вы перестаёте попадать в уже «открытые» блоки и каждая операция записи превращается в полное стирание. Потому и медленно.
== Пример теста ==