тут это было бы тоже лишним, элементарно меняется hot-swap'ом и скармливается массиву без простоя. Пока не посмотришь на картинку самого железа: шанс задеть кабели питания или SATA ещё живых дисков вытаскивая сбойный диск очень высок. Так что и под ZFS всё равно выключать систему понадобилось бы.
Не согласен, у нас как раз схема дежурный-страхующий, поэтому я пользуюсь этой терминологией. Страхующий аналогично подстраивает свою жизнь под дежурство (готовность в любой момент сорваться что-то чинить). При том, "Я основной дежурный" = у меня есть страхующий напарник ведь так и заявлено "Primary может спокойно принять душ, зная что мир не рухнет" "Я страхующий" = если получил звонок, значит больше никто не страхует (был в кино? за рулём едешь по трассе? был в душе? Кроме меня чинить уже некому), а авария, при том, длится как минимум 15 минут.
Страхующий дежурный - это полноценная работа. Да, ниже вероятность вызова, но при этом тот же дискомфорт и плюс выше критичность.
Команда минимум из 6 человек. Меньше — это путь к выгоранию. 6 человек = дежуришь раз в 6 недель. Терпимо. Primary/Secondary модель. Всегда есть подстраховка. Всегда.
Как это совместить? Страхующий тоже дежурный: он обязан отреагировать. Получается или нет подстраховки (дежурят по одному) или в команде из 6 человек каждый дежурит неделю через две или команда из 12 человек чтобы получить дежурства раз в 6 недель.
ничего не произойдёт ни с FK, ни с триггерами, ни с ссылающимися на таблицу чем бы то ни было ещё. Фактически объявление таблицы мы вообще не трогаем, только подменяем relfilenode новым. Это довольно просто и надёжно (в том числе для новых фич), но зато делает невозможным реализацию каких-нибудь на первый взгляд уместных дополнительных возможностей: изменение типа данных колонки, например, или переупорядочивание колонок в таблице.
партицирование умеем. Я рекомендую запускать непосредственно на каждую индивидуальную партицию чем через голову.
visibility map сбросится как побочный эффект, да. Если активно используется index only scan для запроса - ему поплохеет.
pg_repack maintainer и автор патчей для поддержки всех версий postgresql начиная с 11.
Следит за всеми изменениями в оригинальной таблице (использует триггеры и лог WAL).
WAL мы не используем для отслеживания изменений
Создает временную «чистую» таблицу‑копию и индексы. Копирует в нее все актуальные данные.
корректности ради: сначала создаём таблицу, потом пишем в неё копию данных из таблицы-источника, только потом создаём новые индексы
Блокировка все еще нужна, но только на пятом шаге и длится миллисекунды.
блокировку мы вынуждены брать дважды: в самом начале, т.к. create trigger требует аналогично блокировку, и в конце для подмены relfilenode на новые. Миллисекунды блокировки только если никто не мешает (к таблице только быстрые запросы и их можно раздвинуть безболезненно), а вот если к табличке ещё постоянным фоном транзакции по несколько минут - остановите эту активность на время репака либо не ставьте опцию no-kill-backend чтобы репак прибил те транзакции которые мешают взять блокировку.
SELECT repack.repack_table('bloated');
это некорректный способ запуска pg_repack. Если это локальный патч вашего форка - упомяните это, пожалуйста, явно.
по vacuum (не full) - почему в табличке отмечено "Даунтайм для приложения" "да"?
ну и есть у вакуума одна особенность: он действительно может уменьшить таблицу. Но только хвост датафайлов. То есть от конца таблицы до самого дальнего тапла который не был удалён и вычищен. И зная это, если ещё вариант сжатия таблиц: https://github.com/dataegret/pgcompacttable/blob/master/bin/pgcompacttable переместить оставшиеся живые таплы из конца таблицы, затем обычный vacuum действительно вернёт место ОС. Это особо полезно, когда нет троекратного запаса по месту на дисках (на новую копию данных, индексы, и всё это записать в WAL)
Специально придуманные ИБП, ага, как бы не так... В реальной жизни: один ИБП просто вырубает нагрузку "а что, у вас какая-о мелочь там, а мы green!!" другой не включает нагрузку после возвращения электроснабжения пока не ткнёшь кнопку третий именно что не успевает переключиться на батарею, роутер ребутается и попробуй это всё выяснить не экспериментально
О, ключевое слово Pass-Through Charging для поиска это полезно. У меня роутер от type C питается, иногда думаю не заменить ли UPS на повербанк, но непонятно какие смогут работать.
Опять чатгпт писал? Комментарии к pg_stat_statements.track и track_activity_query_size просто неверны, а требуемый для активации pg_stat_statements shared_preload_libraries вовсе не упомянут. total_time в pg_stat_statements давно уже нет, во время добавления total_plan_time (если включен pg_stat_statements.track_planning) был переименован в total_exec_time.
wal_level = archive давным-давно deprecated псевдоним для wal_level = replica
Слот репликации - это механизм, который используется для передачи WAL записей от мастера к реплике без необходимости активного участия реплики.
неверно. Слот физической репликации - это механизм, гарантирующий что у вас переполнится диск на мастере, но не будут удалены WAL, о получении которых ещё не отчиталась реплика. Соответственно, вы вообще никак не пояснили, зачем вам вообще слот репликации. (хинт: он просто не нужен для pitr)
Где вы нашли синтаксис ALTER SLOT для меня, конечно, загадка. Нет такой синтаксической конструкции даже в pg17.
Ну и последнее, но самое важное: вся статья исключительно по EOL версиям postgresql и не подходит для более новых. pg_xlog* функций не существует с pg10, а чтение файла с именем recovery.conf удалил лично я начиная с postgresql 12. Это конечно объясняет пример с archive wal_level, зато вызывает вопросы к "онлайн-курсу"
Да, wal_compression вполне заметно работает, даже при том что только на full page image записях применяется. Сжатие производится до записи WAL как такового, а потому снижает не только объёмы передачи потоковой репликации, но и IO тоже. И к архиву тоже соответственно применяется.
А вот если помимо wal_compression сжимать весь сегмент чем-то ещё сверху - то эффект куда сильнее. Вроде такого
melkij@melkij:/tmp/z$ du -hs *
17M 000000010000003500000034
3,3M 000000010000003500000034.gz
2,2M 000000010000003500000034.zst
Лидер временно может хранить WAL-ов больше, чем указано в параметре wal_keep_size (например, из-за долгой транзакции)
Мастер может в любой конфигурации хранить WAL'ов больше чем указано где-либо потому что ограничения на максимальный объём WAL просто нет. И нет, wal_keep_size не имеет никакого отношения к долгим транзакциям. У нас REDO, не волнует возраст транзакций ни для crash recovery ни для удержания WAL, нас волнует LSN который записали при чекпойнте и соответственно откуда стартовать recovery. А уже при crash recovery смотрим, встретили ли commit запись в WAL или нет.
Вот то, что wal_keep_size держит постоянно занятый объём, я, впрочем, и вовсе как недостаток не рассматриваю - это вполне неплохой удобный резерв наравне с reserved space в ext4. Надо освободить место - оговариваем, что тогда могут отвалиться дальние/медленные реплики. Зато когда медленные реплики действительно отстают - у нас не начинает исчезать свободное место.
Я понимаю, что если тащить WAL-ы из той же Москвы в Новосибирск, то идея с архивной репликацией быстро умрет :)
Я бы кстати наоборот ожидал что на фиговой сети file shipping репликация будет менее проблемная. WAL'ы в виде файликов неплохо сжимаются и сжатие wal просто добавить для архива (по-моему, это вообще дефолтный режим в wal-g). А вот streaming репликация гоняет несжатые данные. При том, потоковая репликация ходит строго одним TCP коннектом. Если нет своих сетевых инженеров для тюнинга сетевого стека, то кучка маленьких параллельных TCP сессий на нестабильной сети наверняка будут работать лучше чем одно долгоживущее.
Ну и в плюсы репликации через архив можно добавить, что для этого способа не надо прорубать сетевое окно на подключение до рабочих баз через всевозможные VPN и файрволы по пути. Базу можно изолировать в закрытом сетевом контуре, куда извне не подключиться. Плюс гибкость выбора транспортировки WAL, хоть по RFC 1149 кидать.
Если вам нужна гарантия, что все WAL сохранены где-то ещё - то начать нужно с вопроса, что вы хотите что бы делала база когда это невозможно. Ну вот буквально, транзакция хочет сделать insert данных. Что делать базе? Разрешить выполнить запись сразу и закоммитить? Всё, тут мы уже нарушили гарантию доставки WAL. У нас есть кусочек WAL, который существует только локально на этой базе и ещё не был никуда скопирован. Для этой задачи нужна синхронная репликация. При том, иметь в виду, что insert в postgresql выполнен будет в любом случае при активной синхронной репликации, синхронная репликация гарантирует что ответ базы "commit выполнен" будет получен после доставки WAL на указанную конфигурацию синхронных реплик. При проблемах с синхронной репликацией останавливается запись данных, но раз просили гарантию сохранности - то вот она цена.
Хотим чтобы реплика могла догнать после существенного отставания репликации? гарантированно? слот репликации без ограничения, либо архив WAL если он очищается с учётом отставания этой реплики. Хочу обратить внимание, что если archive_command перестаёт работать - то база будет накапливать WAL безгранично, подобно слотам репликации max_slot_wal_keep_size. Зато скорей всего под архив WAL получится выделить куда более вместительное и более дешёвое хранилище. Цена той гарантии, что реплика догонит - потенциально неограниченный расход места на хранение WAL. после разумного объёма отставания? wal_keep_size либо слот репликации с max_slot_wal_keep_size, либо архив WAL если тот очищается независимо от отставания реплики
Но вообще архив WAL обычно заводят когда нужен point-in-time-recovery, а не для репликации. И это другая задача. А потом уже, раз всё равно пишем архив WAL, - то можно и задействовать restore_command чтобы из него подтягивать недостающие WAL для отстающих реплик, попутно.
В большинстве production систем действительно лучше потерять реплику и переналить заново, чем уронить мастер с переполнением диска. Поэтому мы почти всегда используем только wal_keep_size. Если реплика отстала до requested WAL segment ... has already been removed и ничего не могли сделать после того как мониторинг сказал что реплика отстаёт - то переналить заново. Зато не потеряли мастер.
restore_command, кстати, имеет одно не очень явно задокументированное свойство: он имеет безусловный приоритет над WAL уже сохранёнными в pg_wal. То есть даже если у вас все WAL есть локально у базы во время старта, то всё равно они будут заново читаться из архива. Поэтому если у вас архив wal не очень быстрый на чтение - то restore_command будет замедлять все рестарты баз.
а можно не "не поддерживает", а "не использует по умолчанию"? Тогда - большинство. Для большинства файловый систем опция discard в linux выключена по-умолчанию. См. https://wiki.archlinux.org/title/Solid_state_drive со ссылками на rhel/ubuntu/debian и вовсе ядро linux с целым списком девайсов с серьёзными ошибками в прошивках, из-за которых для них персонально отключают часть функциональности.
Вместо discard дистрибьютивы обычно делают в кроне или по systemd таймеру вызов fstrim раз в неделю или около того.
Хочу напомнить, что в отличии от распространённых практик другого софта, для mysql х.0 релиз даже изначально не планируется как General Availability релиз, и это даже не бета. Это просто Development Milestone "мы хотим чего-нибудь показать". До General Availability ещё пара лет. Не вижу, чтобы для 8.1 эта политика менялась.
Для нормального использования, конечно, лучше всего TLC
ну вот лет через несколько точно так же и про QLC говорить будут, как про TLC лет 5 назад было "кому нужен одноразовый SSD" Уже и PLC flash из лабораторий выходит, как раз.
так вам просто некуда писать после быстрого заполнения четверти диска для QLC либо трети диска при TLC. Всё, ёмкость кончилась, если до сих пор писали 1 бит в ячейку. Несколько процентов избыточности флеша вам дадут, но ставить 2тб флеша и продавать как 1тб не будут точно. А дальше попадаем на серьёзный штраф времени на erase блока, который исключает всякий смысл неполной записи ячейки. По-моему, возможность ускориться есть только для такого псевдо SLC однобитового режима, или же уже нет смысла (а то и возможности) извращаться и нужно писать номинальное количество бит на ячейку.
Как будет падать график - больше от прошивки контроллера зависит, чем от чего-то другого.
при записи данных во flash это не просто взяли и записали байтики (write), а писать можно только в подготовленные, очищенные ячейки (erase). И вот erase - это весьма долго по сравнению с собственно записью, а ещё может выполняться только блоками относительно физической структуры NAND.
как пишется TLC (да и QLC тоже). Это не взяли битики и записали за один раз все 3 (4 у qlc) битики в ячейку. Процесс многостадийный. Следовательно - более медленный. При этом, есть физическая возможность прерваться после записи одного бита в ячейку, затратив при этом соответственно меньше времени (сильно меньше времени).
Ну и вот она, возможность в бенчмарках показать какие-нибудь красивые цифры. Сообщить (discard) накопителю, что данных на нём нет, дать ему время поработать над erase своих ячеек своего флеша. Дать нагрузку на запись, контроллер делает фокус с записью только одного бита в ячейку. Пока есть свободные ячейки (и не дошли до софтовых ограничений в прошивке, например, использовать только такую-то ёмкость в таком стиле) - получаем качественное ускорение записи. Маркетинг в восторге. А вот как свободные ячейки кончаются, но запись так и не прерывали - скорость записи резко падает. Контроллеру теперь нужно освобождать место на флеше. Читать записанное ранее, переписывать в полноценном TLC режиме, делать erase освобождённых ячеек, писать, в конце концов, то что продолжает требовать записать ОС.
Зато если запись случается нечастыми такими скачками, ОС сообщает об удалении данных (TRIM), а пользователь не забивает диск к 100% - то всё равно остаётся вполне хорошее ускорение для большинства пользователей. Это делают практически все десктопные модели, ориентация на нечастые спринтерские забеги, но не под постоянную запись. Ну а то что маркетинг об этом, разумеется, не скажет - как будто что-то неожиданное.
Да и многие серверные делают так же, вполне себе состоялось деление на разные семейства SSD под Read Intensive (см. выше) или же write-intensive (запись будет плюс-минус стабильна под постоянной пишущей нагрузкой, но дорого).
ну, на самом деле действительно нетипично на сервере ставить систему, которой осталось пара недель до EOL. Вообще не LTS убунта на сервере настораживает.
тут это было бы тоже лишним, элементарно меняется hot-swap'ом и скармливается массиву без простоя. Пока не посмотришь на картинку самого железа: шанс задеть кабели питания или SATA ещё живых дисков вытаскивая сбойный диск очень высок. Так что и под ZFS всё равно выключать систему понадобилось бы.
Не согласен, у нас как раз схема дежурный-страхующий, поэтому я пользуюсь этой терминологией. Страхующий аналогично подстраивает свою жизнь под дежурство (готовность в любой момент сорваться что-то чинить). При том,
"Я основной дежурный" = у меня есть страхующий напарник ведь так и заявлено "Primary может спокойно принять душ, зная что мир не рухнет"
"Я страхующий" = если получил звонок, значит больше никто не страхует (был в кино? за рулём едешь по трассе? был в душе? Кроме меня чинить уже некому), а авария, при том, длится как минимум 15 минут.
Страхующий дежурный - это полноценная работа. Да, ниже вероятность вызова, но при этом тот же дискомфорт и плюс выше критичность.
Как это совместить? Страхующий тоже дежурный: он обязан отреагировать. Получается или нет подстраховки (дежурят по одному) или в команде из 6 человек каждый дежурит неделю через две или команда из 12 человек чтобы получить дежурства раз в 6 недель.
а лучше сразу раскатить
PasswordAuthentication noничего не произойдёт ни с FK, ни с триггерами, ни с ссылающимися на таблицу чем бы то ни было ещё. Фактически объявление таблицы мы вообще не трогаем, только подменяем relfilenode новым. Это довольно просто и надёжно (в том числе для новых фич), но зато делает невозможным реализацию каких-нибудь на первый взгляд уместных дополнительных возможностей: изменение типа данных колонки, например, или переупорядочивание колонок в таблице.
партицирование умеем. Я рекомендую запускать непосредственно на каждую индивидуальную партицию чем через голову.
visibility map сбросится как побочный эффект, да. Если активно используется index only scan для запроса - ему поплохеет.
pg_repack maintainer и автор патчей для поддержки всех версий postgresql начиная с 11.
WAL мы не используем для отслеживания изменений
корректности ради: сначала создаём таблицу, потом пишем в неё копию данных из таблицы-источника, только потом создаём новые индексы
блокировку мы вынуждены брать дважды: в самом начале, т.к. create trigger требует аналогично блокировку, и в конце для подмены relfilenode на новые.
Миллисекунды блокировки только если никто не мешает (к таблице только быстрые запросы и их можно раздвинуть безболезненно), а вот если к табличке ещё постоянным фоном транзакции по несколько минут - остановите эту активность на время репака либо не ставьте опцию no-kill-backend чтобы репак прибил те транзакции которые мешают взять блокировку.
это некорректный способ запуска pg_repack. Если это локальный патч вашего форка - упомяните это, пожалуйста, явно.
по vacuum (не full) - почему в табличке отмечено "Даунтайм для приложения" "да"?
ну и есть у вакуума одна особенность: он действительно может уменьшить таблицу. Но только хвост датафайлов. То есть от конца таблицы до самого дальнего тапла который не был удалён и вычищен. И зная это, если ещё вариант сжатия таблиц: https://github.com/dataegret/pgcompacttable/blob/master/bin/pgcompacttable
переместить оставшиеся живые таплы из конца таблицы, затем обычный vacuum действительно вернёт место ОС. Это особо полезно, когда нет троекратного запаса по месту на дисках (на новую копию данных, индексы, и всё это записать в WAL)
а дальше куда? Нет же какого-либо видеовыхода?
Специально придуманные ИБП, ага, как бы не так... В реальной жизни:
один ИБП просто вырубает нагрузку "а что, у вас какая-о мелочь там, а мы green!!"
другой не включает нагрузку после возвращения электроснабжения пока не ткнёшь кнопку
третий именно что не успевает переключиться на батарею, роутер ребутается
и попробуй это всё выяснить не экспериментально
О, ключевое слово Pass-Through Charging для поиска это полезно. У меня роутер от type C питается, иногда думаю не заменить ли UPS на повербанк, но непонятно какие смогут работать.
Опять чатгпт писал?
Комментарии к pg_stat_statements.track и track_activity_query_size просто неверны, а требуемый для активации pg_stat_statements shared_preload_libraries вовсе не упомянут.
total_time в pg_stat_statements давно уже нет, во время добавления total_plan_time (если включен pg_stat_statements.track_planning) был переименован в total_exec_time.
wal_level = archive давным-давно deprecated псевдоним для wal_level = replica
неверно. Слот физической репликации - это механизм, гарантирующий что у вас переполнится диск на мастере, но не будут удалены WAL, о получении которых ещё не отчиталась реплика.
Соответственно, вы вообще никак не пояснили, зачем вам вообще слот репликации. (хинт: он просто не нужен для pitr)
Где вы нашли синтаксис ALTER SLOT для меня, конечно, загадка. Нет такой синтаксической конструкции даже в pg17.
Ну и последнее, но самое важное: вся статья исключительно по EOL версиям postgresql и не подходит для более новых. pg_xlog* функций не существует с pg10, а чтение файла с именем recovery.conf удалил лично я начиная с postgresql 12. Это конечно объясняет пример с archive wal_level, зато вызывает вопросы к "онлайн-курсу"
Да, wal_compression вполне заметно работает, даже при том что только на full page image записях применяется. Сжатие производится до записи WAL как такового, а потому снижает не только объёмы передачи потоковой репликации, но и IO тоже. И к архиву тоже соответственно применяется.
А вот если помимо wal_compression сжимать весь сегмент чем-то ещё сверху - то эффект куда сильнее. Вроде такого
Мастер может в любой конфигурации хранить WAL'ов больше чем указано где-либо потому что ограничения на максимальный объём WAL просто нет.
И нет, wal_keep_size не имеет никакого отношения к долгим транзакциям. У нас REDO, не волнует возраст транзакций ни для crash recovery ни для удержания WAL, нас волнует LSN который записали при чекпойнте и соответственно откуда стартовать recovery. А уже при crash recovery смотрим, встретили ли commit запись в WAL или нет.
Вот то, что wal_keep_size держит постоянно занятый объём, я, впрочем, и вовсе как недостаток не рассматриваю - это вполне неплохой удобный резерв наравне с reserved space в ext4. Надо освободить место - оговариваем, что тогда могут отвалиться дальние/медленные реплики. Зато когда медленные реплики действительно отстают - у нас не начинает исчезать свободное место.
Я бы кстати наоборот ожидал что на фиговой сети file shipping репликация будет менее проблемная. WAL'ы в виде файликов неплохо сжимаются и сжатие wal просто добавить для архива (по-моему, это вообще дефолтный режим в wal-g). А вот streaming репликация гоняет несжатые данные. При том, потоковая репликация ходит строго одним TCP коннектом. Если нет своих сетевых инженеров для тюнинга сетевого стека, то кучка маленьких параллельных TCP сессий на нестабильной сети наверняка будут работать лучше чем одно долгоживущее.
Ну и в плюсы репликации через архив можно добавить, что для этого способа не надо прорубать сетевое окно на подключение до рабочих баз через всевозможные VPN и файрволы по пути. Базу можно изолировать в закрытом сетевом контуре, куда извне не подключиться.
Плюс гибкость выбора транспортировки WAL, хоть по RFC 1149 кидать.
Как обычно, какую задачу решаем?
Если вам нужна гарантия, что все WAL сохранены где-то ещё - то начать нужно с вопроса, что вы хотите что бы делала база когда это невозможно. Ну вот буквально, транзакция хочет сделать insert данных. Что делать базе? Разрешить выполнить запись сразу и закоммитить? Всё, тут мы уже нарушили гарантию доставки WAL. У нас есть кусочек WAL, который существует только локально на этой базе и ещё не был никуда скопирован. Для этой задачи нужна синхронная репликация. При том, иметь в виду, что insert в postgresql выполнен будет в любом случае при активной синхронной репликации, синхронная репликация гарантирует что ответ базы "commit выполнен" будет получен после доставки WAL на указанную конфигурацию синхронных реплик. При проблемах с синхронной репликацией останавливается запись данных, но раз просили гарантию сохранности - то вот она цена.
Хотим чтобы реплика могла догнать после существенного отставания репликации?
гарантированно? слот репликации без ограничения, либо архив WAL если он очищается с учётом отставания этой реплики. Хочу обратить внимание, что если archive_command перестаёт работать - то база будет накапливать WAL безгранично, подобно слотам репликации max_slot_wal_keep_size. Зато скорей всего под архив WAL получится выделить куда более вместительное и более дешёвое хранилище. Цена той гарантии, что реплика догонит - потенциально неограниченный расход места на хранение WAL.
после разумного объёма отставания? wal_keep_size либо слот репликации с max_slot_wal_keep_size, либо архив WAL если тот очищается независимо от отставания реплики
Но вообще архив WAL обычно заводят когда нужен point-in-time-recovery, а не для репликации. И это другая задача. А потом уже, раз всё равно пишем архив WAL, - то можно и задействовать restore_command чтобы из него подтягивать недостающие WAL для отстающих реплик, попутно.
В большинстве production систем действительно лучше потерять реплику и переналить заново, чем уронить мастер с переполнением диска. Поэтому мы почти всегда используем только wal_keep_size. Если реплика отстала до requested WAL segment ... has already been removed и ничего не могли сделать после того как мониторинг сказал что реплика отстаёт - то переналить заново. Зато не потеряли мастер.
restore_command, кстати, имеет одно не очень явно задокументированное свойство: он имеет безусловный приоритет над WAL уже сохранёнными в pg_wal. То есть даже если у вас все WAL есть локально у базы во время старта, то всё равно они будут заново читаться из архива. Поэтому если у вас архив wal не очень быстрый на чтение - то restore_command будет замедлять все рестарты баз.
а можно не "не поддерживает", а "не использует по умолчанию"? Тогда - большинство. Для большинства файловый систем опция discard в linux выключена по-умолчанию. См. https://wiki.archlinux.org/title/Solid_state_drive со ссылками на rhel/ubuntu/debian и вовсе ядро linux с целым списком девайсов с серьёзными ошибками в прошивках, из-за которых для них персонально отключают часть функциональности.
Вместо discard дистрибьютивы обычно делают в кроне или по systemd таймеру вызов fstrim раз в неделю или около того.
Хочу напомнить, что в отличии от распространённых практик другого софта, для mysql х.0 релиз даже изначально не планируется как General Availability релиз, и это даже не бета. Это просто Development Milestone "мы хотим чего-нибудь показать". До General Availability ещё пара лет.
Не вижу, чтобы для 8.1 эта политика менялась.
ну вот лет через несколько точно так же и про QLC говорить будут, как про TLC лет 5 назад было "кому нужен одноразовый SSD"
Уже и PLC flash из лабораторий выходит, как раз.
так вам просто некуда писать после быстрого заполнения четверти диска для QLC либо трети диска при TLC. Всё, ёмкость кончилась, если до сих пор писали 1 бит в ячейку. Несколько процентов избыточности флеша вам дадут, но ставить 2тб флеша и продавать как 1тб не будут точно.
А дальше попадаем на серьёзный штраф времени на erase блока, который исключает всякий смысл неполной записи ячейки. По-моему, возможность ускориться есть только для такого псевдо SLC однобитового режима, или же уже нет смысла (а то и возможности) извращаться и нужно писать номинальное количество бит на ячейку.
Как будет падать график - больше от прошивки контроллера зависит, чем от чего-то другого.
Неа, одинаковые там чипы. Нюанса два:
при записи данных во flash это не просто взяли и записали байтики (write), а писать можно только в подготовленные, очищенные ячейки (erase). И вот erase - это весьма долго по сравнению с собственно записью, а ещё может выполняться только блоками относительно физической структуры NAND.
как пишется TLC (да и QLC тоже). Это не взяли битики и записали за один раз все 3 (4 у qlc) битики в ячейку. Процесс многостадийный. Следовательно - более медленный. При этом, есть физическая возможность прерваться после записи одного бита в ячейку, затратив при этом соответственно меньше времени (сильно меньше времени).
Ну и вот она, возможность в бенчмарках показать какие-нибудь красивые цифры. Сообщить (discard) накопителю, что данных на нём нет, дать ему время поработать над erase своих ячеек своего флеша. Дать нагрузку на запись, контроллер делает фокус с записью только одного бита в ячейку. Пока есть свободные ячейки (и не дошли до софтовых ограничений в прошивке, например, использовать только такую-то ёмкость в таком стиле) - получаем качественное ускорение записи. Маркетинг в восторге.
А вот как свободные ячейки кончаются, но запись так и не прерывали - скорость записи резко падает. Контроллеру теперь нужно освобождать место на флеше. Читать записанное ранее, переписывать в полноценном TLC режиме, делать erase освобождённых ячеек, писать, в конце концов, то что продолжает требовать записать ОС.
Зато если запись случается нечастыми такими скачками, ОС сообщает об удалении данных (TRIM), а пользователь не забивает диск к 100% - то всё равно остаётся вполне хорошее ускорение для большинства пользователей. Это делают практически все десктопные модели, ориентация на нечастые спринтерские забеги, но не под постоянную запись. Ну а то что маркетинг об этом, разумеется, не скажет - как будто что-то неожиданное.
Да и многие серверные делают так же, вполне себе состоялось деление на разные семейства SSD под Read Intensive (см. выше) или же write-intensive (запись будет плюс-минус стабильна под постоянной пишущей нагрузкой, но дорого).
ну, на самом деле действительно нетипично на сервере ставить систему, которой осталось пара недель до EOL. Вообще не LTS убунта на сервере настораживает.