ну, на самом деле действительно нетипично на сервере ставить систему, которой осталось пара недель до EOL. Вообще не LTS убунта на сервере настораживает.
железо: поизучать наработки годов этак 2006-2012 overclokers, fcenter, ixbt и других грандов былых времён по части тестовых стендов и методик сравнения различающегося железа. Особенно методики тестирования i7 920 как первого 3-канальника. Какие шишки на нём собрали, как сглаживали эффекты различия объёма, как тестировали изменение числа каналов памяти.
одну и ту же пару дисков переставлять физически в каждый сервер. В начале короткий fio минут на 5 для детектирования аномалий, различия результатов теста между серверами, понятное дело, должно быть минимально. Если это не так - то искать причину. желательно использовать одну и ту же коллекцию модулей памяти, с проверкой что они стартуют в одинаковом режиме частота&тайминги среди всех участников влияние разной конфигурации заполнения слотов памяти - идея для тестирования платформы в отдельности, на самом деле. Это лично мне, кстати, действительно интересно - имеет ли значение число каналов памяти кроме как для увеличения максимального объёма памяти. Максимум памяти в реальности не столь актуален для СУБД, даже террабайт RAM очень мало кто ставит, а вот есть ли смысл просить именно задействовать каналы памяти, а не добить до нужного объёма теми модулями что под рукой нашлись? на разных платформах соответственно дать настолько близкую разбивку модулей по каналам и сокетам насколько получится, различия задокументировать контроль температуры и троттлинга на протяжении тестов (для серверов тоже не шутка, да, была у нас машинка в ovh (вполне серверный xeon D-2141I, не десктоп), которая под нагрузкой перегревалась и сбрасывала частоту CPU втрое)
ОС: NUMA. NUMA это проблема. Честно не знаю как сглаживать его артефакты кроме как переключением всей системы в interleave либо сознательно через numactl тестировать только половину сервера. Особое счастье с EPYC'ами, где по 4 NUMA ноды бывает даже в одном сокете. cpu performance mode. В реальности под базой данных CPU решает выходить из powersafe и поднимать частоту до рабочей довольно поздно (мой опыт - это разница в полтора раза по графикам среднего времени выполнения запросов от веба). Но главное для теста - непостоянно. performance mode нам тоже не даст постоянную рабочую частоту, но куда лучше чем powersafe.
postgres ох (с) сейчас я упомянут даже в списках разработчиков postgresql, но понимания как корректно тестировать его производительность стало даже меньше, чем когда я про него даже не знал =) pgbech - ну, это pgbench. Чистая синтетика, довольно бесполезная сама по себе. А вот что-то полезное моделировать... (за это DBA не любят детей ораклового маркетинга "у нас 10k tps, справится postgres?" - каких именно транзакций-то?) Разглядел, кстати, затаивщийся в опциях scale factor, с первого раза не признал его в краткой форме. То есть примерно 150гб рабочий набор у вас на начало теста. Боюсь, что на самом деле протестировали менеджер локов и реализацию spinlock нежели собственно производительность запросов: все операции над данными postgres выполняет только в shared_buffers, а он в дефолте аж целых 128МБ. Получается конкурентные процессы активно дрались между собой, чтобы скопировать из page cache системного в shared buffers нужный именно этому процессу блок (памяти явно достаточно во всех случаях, чтобы реально на диск только писать, но не читать). А вот со spinlock'ами на ARM у postgresql действительно не всё хорошо: https://www.postgresql.org/message-id/flat/CAB10pyamDkTFWU_BVGeEVmkc8%3DEhgCjr6QBk02SCdJtKpHkdFw%40mail.gmail.com Скорей всего так до сих пор не оптимальный машинный код и компилируется в GCC для ARM. Поскольку тестировать хотим CPU, в меньшей мере память и не хотим диск, то стоит поставить shared_buffers гигабайт в 180 (хотя на сотне процессов уже может отвалиться вот тот конфиг на 192гб памяти с OOM), synchronous_commit = off. huge_pages = on на таком объёме памяти уже точно нужен (соответственно в ОС тоже выделить huge pages)
PS: я понимаю почему выбрана модель "специально ничего не настраиваем", в этом есть смысл, но по моему опыту shared_buffers всё-таки пользователи крутят чуть менее чем всегда, думаю полезнее чем дефолтные 128мб тестировать будет.
Не всегда, да. Но вы это не указали в статье. Поискал внимательнее, в описании конфигурации вы вообще никак не упоминаете ни модели дисков, ни что они хотя бы одноклассники. Честно не помню, какие диски вы ставите обычно, для нас вы собирали кастомные конфигурации с оговорёнными конкретными моделями дисков под write intensive базы. Но часто если хостер говорит в описании что поставит абстрактное "2 × 960 ГБ SSD NVMe", то на двух одинаковых заказанных одновременно серверах запросто можно увидеть разные диски (а то и на одном сервере две разные модели, привет hetzner'у).
Различие конфигурации должно устраняться или хотя бы подтверждаться тестом, что оно не является значимым фактором для результата тестирования. У вас есть тест, что различие в объёме RAM 192 и 512гб не имеет значения для результата теста? (а про частоту и тайминги вы тоже не писали в статье) В частности, вы так же не указали, сколько у вас каналов памяти вообще работает. Для того же восьмиканального 6336Y может быть значимым различие, установлено ли 16 модулей по 16гб или 8 по 32гб или максимальным поддерживаемым объёмом одного DIMM (4 по 64? 2 по 128?).
Объём разный. Особенно на не топовых по объёму моделях это очень часто означает разницу производительности. Иногда кратную. Ну например, самсунговый PM9A3 https://semiconductor.samsung.com/ssd/datacenter-ssd/pm9a3/ : объёмом 960гб - 70к IOPS random write, а 1920гб - уже 130к IOPS. Почти двукратно по спецификации. Что там в реальности - тема отдельного вдумчивого теста.
ну я понимаю маркетинг, но заявлять что сравниваете производительность ARM и x86 в базах данных, но ставить разные диски участникам? Это же в принципе лишено смысла. В сравнении должен быть минимум различий. Одна и та же физически пара накопителей должна переставляться с сервера на сервер для корректного сравнения возможностей именно CPU, а не дисков.
Аналогично по RAM, впрочем я не вижу у вас scale factor, так что от него значение меньше.
Корректный заголовок "погоняем синтетику на наших тарифах", исключив при этом из теста кастомную конфигурацию.
У listen/notify, конечно, вагон своих особенностей (начиная с того что они принципиально не crash safe), но советовать вместо них, упирая именно на производительность обработки, наиболее топорную самодельную очередь в базе? Очередь в базе - известный антипаттерн, приводит к головной боли.
work mem же... Вот сначала совершенно верно написано "сколько памяти доступно каждой операции запроса", а потом приводится классический неверный совет делить поровну на max_connections. Неверный именно потому, что work_mem - это память на одну операцию. И то без учёта hash_mem_multiplier. Один сложный OLAP запрос может сожрать десятки work_mem. Поэтому выставляется в разумное значение и отслеживаются потребности. pg_stat_statements тот же пишет temp_blk_write_time и temp_blk_read_time. Вполне обычная ситуация, когда для OLTP части work_mem небольшой, десятки мегабайт, а для пользователей со всякими отчётами work_mem выставлен именно на пользователя побольше. Или в целом на отдельной реплике, куда не ходят на OLTP данными.
справедливости ради, вы всё-таки не правы про "не планировавшиеся еще несколькими месяцами ранее", мне письмо счастья пришло ещё 14 декабря (за 4 полных месяца), первые получившие такие письма чуть ли не с ноября начали появляться. С этой стороны претензий нет, сообщили вполне заранее.
а других, с точки зрения самого яндекса, нет. Не предложено никакого деления на личные и корпоративные. У меня, говорят, пяток "сотрудников". А пару недель назад пройти опрос предлагали, где ОГРН было сделано обязательным для заполнения полем. Вопрос, что это просто личный домен одного человека (ну или семьи, как упоминается в статье) - просто проигнорирован и всех назвали бизнесом.
не в одно лицо, а в один ящик. Я лицо одно (да и то физическое, а не юридическое), но было несколько ящиков - поэтому меня поставили перед фактом "оплата за каждый ящик отдельно".
В Linux на текущий момент существует четыре планировщика ввода-вывода:
ни одного из перечисленных на текущий момент уже не существует. Удалены в ядре, теперь используется более новая blk-mq подсистема. В основном none (это не тот none что был ранее), mq-deadline, bfq или kyber
Электронный архив на 50 лет - это не большая проприетарная система всё-в-одном, а "сделай это проще". И ещё проще. Никаких проприетарных и сложных форматов данных. Как можно проще и чуть-чуть от "да уже нельзя проще". Сегодня эта система есть, а уже завтра закрылась и плакал ваш архив. Сегодня этот формат документа всюду, а через 15 лет это отдельный квест открыть его посмотреть ну хоть где-нибудь.
И отдельно, при сохранении основополагающего для него принципа KISS, как этот архив регулярно верифицировать на предмет искажения данных и хранить на железе в достаточном для восстановлении количестве копий. На горизонте в 50 лет "ой этот файл когда-то как-то побился и теперь его не прочитать" - гарантирован.
А если хочется каких-то сложностей для облегчения работы сейчас - это только сбоку от архива. Что в случае чего выкинуть конечно жалко, но не угрожает сохранности самого архива.
Это если система шифрования вообще пытается скрывать своё существование, а не имеет открытый характерный для него суперблок "привет, я LUKS такой-то версии, зашифрован таким-то алгоритмом, данные начинаются с такого смещения". Работающий TRIM на шифрованном разделе раскроет понимание сколько примерно реальных данных лежит на разделе и можно попытаться угадать используемую файловую систему.
Allow using of discards (TRIM) requests for device. Starting with Debian 10 (Buster), this option is added per default to new dm-crypt devices by the Debian Installer. If you don't care about leaking access patterns (filesystem type, used space) and don't have hidden truecrypt volumes inside this volume, then it should be safe to enable this option. See the following warning for further information. WARNING: Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.
Не поверите, мне такие серверные попадались. Где в случайные моменты времени на пару минут латентность записи взлетает до секунды (!) и даже выше.
Так вот в таких дисках память состоит из двух типов чипов
Неа, нет там второго чипа, он же денег стоит. Один и тот же TLC и есть. Фокус в том, как именно пишется ячейка TLC или QLC — нетривиально она пишется. При этом есть возможность в ячейку TLC записать только 1 бит данных вместо 3 (4 у QLC) затратив на это заметно меньше времени. Поэтому в часть свободных ячеек можно писать со скоростью повыше. Это маркетинг нынче и называет SLC кэшом. Именно потому такому кэшу и становится грустно, когда накопитель оказывается заполнен ближе к заявленной ёмкости — уже нет достаточного числа свободных ячеек куда можно писать только 1 бит из положенных 3.
Так практически все десктопные модели делают, за очень-очень редким исключением. Разница в том, что происходит после исчерпания кэша быстрой записи, да. Кто-то замедляется в пару раз без явных перекосов отзывчивости до ещё приличных значений сильно выше HDD, а кто-то начинает страдать.
Можете на уровне культа доверять HDD и верить что за весьма нескромный ценник вам поможет лаборатория, ваше право. Или ещё какому накопителю. Кто-то в надёжность DVD верит, кто-то ещё во что-то.
Но если данные важны — резервной копией озаботиться придётся. Как минимум одной. Это не опция, а необходимость. Либо на самом деле эти данные были не нужны.
Да, это проблема нашей цивилизации вообще как таковой, у человечества нет технологии надёжного сохранения данных.
Не надо DBA рассказывать о паттернах записи СУБД ;-)
Да, совершенно верно, отдельная группа HDD, выделенных монопольно под WAL — это именно что «исчезающе уникальное явление», иначе не сказать. Когда-то давно, когда сотня гигов места на SSD было очень дорого, такое практиковалось и было хорошей идеей. Но сейчас HDD уже слишком медлительны даже чисто под WAL. Критичное здесь опять же: во-первых latency на несколько порядков выше SSD, а значит каждый коммит выполняется медленнее, во-вторых — в принципе предел по скорости последовательной записи. Базе писать WAL со скоростью в сотню-другую мегабайт в секунду не так сложно как может показаться. А вот механика начинает захлёбываться от такого счастья. Добавлять ещё шпинделей? Но зачем страдать?
Вот про видеонаблюдение я не компетентен, согласен.
несмотря на устаревание винчестеров как таковых, покупать более дешевые SSD для тяжелых нагрузок уж точно не стоит.
Фраза так построена, будто предполагает вообще наличие возможности оставить механику в таком месте.
Да ничего подобного. Недорогие Read Intensive SSD плохо годятся для интенсивной записи, это верно, но нюанс в том, что там где есть интенсивный IO — механике делать вообще давно уже нечего. Уровни производительности даже дешёвых SSD давно уже недостижимы для HDD. Даже если у вас будут сотни шпинделей — разницу в латентности на несколько порядков вы так не компенсируете.
Единственный оптимальных сценарий нагрузки HDD — последовательное чтение или запись одним потоком — слишком уникален и не встречается в реальности. Но SMR диски и этот сценарий старательно хоронят.
Если вы что-то серьёзное храните только на одном накопителе — то свойства этого накопителя не имеют никакого значения. Это значит, что на самом деле вам эти данные были не нужны.
ну, на самом деле действительно нетипично на сервере ставить систему, которой осталось пара недель до EOL. Вообще не LTS убунта на сервере настораживает.
performance testing is the state of art (c)
железо:
поизучать наработки годов этак 2006-2012 overclokers, fcenter, ixbt и других грандов былых времён по части тестовых стендов и методик сравнения различающегося железа. Особенно методики тестирования i7 920 как первого 3-канальника. Какие шишки на нём собрали, как сглаживали эффекты различия объёма, как тестировали изменение числа каналов памяти.
одну и ту же пару дисков переставлять физически в каждый сервер. В начале короткий fio минут на 5 для детектирования аномалий, различия результатов теста между серверами, понятное дело, должно быть минимально. Если это не так - то искать причину.
желательно использовать одну и ту же коллекцию модулей памяти, с проверкой что они стартуют в одинаковом режиме частота&тайминги среди всех участников
влияние разной конфигурации заполнения слотов памяти - идея для тестирования платформы в отдельности, на самом деле. Это лично мне, кстати, действительно интересно - имеет ли значение число каналов памяти кроме как для увеличения максимального объёма памяти. Максимум памяти в реальности не столь актуален для СУБД, даже террабайт RAM очень мало кто ставит, а вот есть ли смысл просить именно задействовать каналы памяти, а не добить до нужного объёма теми модулями что под рукой нашлись?
на разных платформах соответственно дать настолько близкую разбивку модулей по каналам и сокетам насколько получится, различия задокументировать
контроль температуры и троттлинга на протяжении тестов (для серверов тоже не шутка, да, была у нас машинка в ovh (вполне серверный xeon D-2141I, не десктоп), которая под нагрузкой перегревалась и сбрасывала частоту CPU втрое)
ОС:
NUMA. NUMA это проблема. Честно не знаю как сглаживать его артефакты кроме как переключением всей системы в interleave либо сознательно через numactl тестировать только половину сервера. Особое счастье с EPYC'ами, где по 4 NUMA ноды бывает даже в одном сокете.
cpu performance mode. В реальности под базой данных CPU решает выходить из powersafe и поднимать частоту до рабочей довольно поздно (мой опыт - это разница в полтора раза по графикам среднего времени выполнения запросов от веба). Но главное для теста - непостоянно. performance mode нам тоже не даст постоянную рабочую частоту, но куда лучше чем powersafe.
postgres
ох (с)
сейчас я упомянут даже в списках разработчиков postgresql, но понимания как корректно тестировать его производительность стало даже меньше, чем когда я про него даже не знал =)
pgbech - ну, это pgbench. Чистая синтетика, довольно бесполезная сама по себе. А вот что-то полезное моделировать... (за это DBA не любят детей ораклового маркетинга "у нас 10k tps, справится postgres?" - каких именно транзакций-то?)
Разглядел, кстати, затаивщийся в опциях scale factor, с первого раза не признал его в краткой форме. То есть примерно 150гб рабочий набор у вас на начало теста. Боюсь, что на самом деле протестировали менеджер локов и реализацию spinlock нежели собственно производительность запросов: все операции над данными postgres выполняет только в shared_buffers, а он в дефолте аж целых 128МБ. Получается конкурентные процессы активно дрались между собой, чтобы скопировать из page cache системного в shared buffers нужный именно этому процессу блок (памяти явно достаточно во всех случаях, чтобы реально на диск только писать, но не читать). А вот со spinlock'ами на ARM у postgresql действительно не всё хорошо: https://www.postgresql.org/message-id/flat/CAB10pyamDkTFWU_BVGeEVmkc8%3DEhgCjr6QBk02SCdJtKpHkdFw%40mail.gmail.com Скорей всего так до сих пор не оптимальный машинный код и компилируется в GCC для ARM.
Поскольку тестировать хотим CPU, в меньшей мере память и не хотим диск, то стоит поставить shared_buffers гигабайт в 180 (хотя на сотне процессов уже может отвалиться вот тот конфиг на 192гб памяти с OOM), synchronous_commit = off. huge_pages = on на таком объёме памяти уже точно нужен (соответственно в ОС тоже выделить huge pages)
PS: я понимаю почему выбрана модель "специально ничего не настраиваем", в этом есть смысл, но по моему опыту shared_buffers всё-таки пользователи крутят чуть менее чем всегда, думаю полезнее чем дефолтные 128мб тестировать будет.
Не всегда, да. Но вы это не указали в статье. Поискал внимательнее, в описании конфигурации вы вообще никак не упоминаете ни модели дисков, ни что они хотя бы одноклассники. Честно не помню, какие диски вы ставите обычно, для нас вы собирали кастомные конфигурации с оговорёнными конкретными моделями дисков под write intensive базы. Но часто если хостер говорит в описании что поставит абстрактное "2 × 960 ГБ SSD NVMe", то на двух одинаковых заказанных одновременно серверах запросто можно увидеть разные диски (а то и на одном сервере две разные модели, привет hetzner'у).
Различие конфигурации должно устраняться или хотя бы подтверждаться тестом, что оно не является значимым фактором для результата тестирования. У вас есть тест, что различие в объёме RAM 192 и 512гб не имеет значения для результата теста? (а про частоту и тайминги вы тоже не писали в статье)
В частности, вы так же не указали, сколько у вас каналов памяти вообще работает. Для того же восьмиканального 6336Y может быть значимым различие, установлено ли 16 модулей по 16гб или 8 по 32гб или максимальным поддерживаемым объёмом одного DIMM (4 по 64? 2 по 128?).
Объём разный. Особенно на не топовых по объёму моделях это очень часто означает разницу производительности. Иногда кратную.
Ну например, самсунговый PM9A3 https://semiconductor.samsung.com/ssd/datacenter-ssd/pm9a3/ :
объёмом 960гб - 70к IOPS random write, а 1920гб - уже 130к IOPS. Почти двукратно по спецификации. Что там в реальности - тема отдельного вдумчивого теста.
ну я понимаю маркетинг, но заявлять что сравниваете производительность ARM и x86 в базах данных, но ставить разные диски участникам? Это же в принципе лишено смысла. В сравнении должен быть минимум различий. Одна и та же физически пара накопителей должна переставляться с сервера на сервер для корректного сравнения возможностей именно CPU, а не дисков.
Аналогично по RAM, впрочем я не вижу у вас scale factor, так что от него значение меньше.
Корректный заголовок "погоняем синтетику на наших тарифах", исключив при этом из теста кастомную конфигурацию.
У listen/notify, конечно, вагон своих особенностей (начиная с того что они принципиально не crash safe), но советовать вместо них, упирая именно на производительность обработки, наиболее топорную самодельную очередь в базе? Очередь в базе - известный антипаттерн, приводит к головной боли.
work mem же... Вот сначала совершенно верно написано "сколько памяти доступно каждой операции запроса", а потом приводится классический неверный совет делить поровну на max_connections. Неверный именно потому, что work_mem - это память на одну операцию. И то без учёта hash_mem_multiplier. Один сложный OLAP запрос может сожрать десятки work_mem. Поэтому выставляется в разумное значение и отслеживаются потребности. pg_stat_statements тот же пишет temp_blk_write_time и temp_blk_read_time. Вполне обычная ситуация, когда для OLTP части work_mem небольшой, десятки мегабайт, а для пользователей со всякими отчётами work_mem выставлен именно на пользователя побольше. Или в целом на отдельной реплике, куда не ходят на OLTP данными.
справедливости ради, вы всё-таки не правы про "не планировавшиеся еще несколькими месяцами ранее", мне письмо счастья пришло ещё 14 декабря (за 4 полных месяца), первые получившие такие письма чуть ли не с ноября начали появляться.
С этой стороны претензий нет, сообщили вполне заранее.
а других, с точки зрения самого яндекса, нет. Не предложено никакого деления на личные и корпоративные. У меня, говорят, пяток "сотрудников". А пару недель назад пройти опрос предлагали, где ОГРН было сделано обязательным для заполнения полем.
Вопрос, что это просто личный домен одного человека (ну или семьи, как упоминается в статье) - просто проигнорирован и всех назвали бизнесом.
не в одно лицо, а в один ящик. Я лицо одно (да и то физическое, а не юридическое), но было несколько ящиков - поэтому меня поставили перед фактом "оплата за каждый ящик отдельно".
ни одного из перечисленных на текущий момент уже не существует. Удалены в ядре, теперь используется более новая blk-mq подсистема. В основном none (это не тот none что был ранее), mq-deadline, bfq или kyber
Перед использованием listen/notify внимательно прочитать что про этот механизм обещает сама база: https://github.com/postgres/postgres/blob/REL_15_STABLE/src/backend/commands/async.c#L16
Чтобы потом не было неожиданностью, что все нотификации, к примеру, принципиально не crash-safe.
Электронный архив на 50 лет - это не большая проприетарная система всё-в-одном, а "сделай это проще". И ещё проще. Никаких проприетарных и сложных форматов данных. Как можно проще и чуть-чуть от "да уже нельзя проще". Сегодня эта система есть, а уже завтра закрылась и плакал ваш архив. Сегодня этот формат документа всюду, а через 15 лет это отдельный квест открыть его посмотреть ну хоть где-нибудь.
И отдельно, при сохранении основополагающего для него принципа KISS, как этот архив регулярно верифицировать на предмет искажения данных и хранить на железе в достаточном для восстановлении количестве копий. На горизонте в 50 лет "ой этот файл когда-то как-то побился и теперь его не прочитать" - гарантирован.
А если хочется каких-то сложностей для облегчения работы сейчас - это только сбоку от архива. Что в случае чего выкинуть конечно жалко, но не угрожает сохранности самого архива.
Это если система шифрования вообще пытается скрывать своё существование, а не имеет открытый характерный для него суперблок "привет, я LUKS такой-то версии, зашифрован таким-то алгоритмом, данные начинаются с такого смещения".
Работающий TRIM на шифрованном разделе раскроет понимание сколько примерно реальных данных лежит на разделе и можно попытаться угадать используемую файловую систему.
Процитирую debian: https://manpages.debian.org/bullseye/cryptsetup/crypttab.5.en.html
я понимаю, что биллинг - дело не быстрое, но уже ноябрь проходит. Что подразумевалось под ближайшим временем?
Это сарказм был =) Да, разумеется, нельзя рассчитывать ни что SSD уйдёт в read-only, ни что HDD предупредит о проблемах. Могут быть сюрпризы внезапно на ровном месте.
Там и чисто софтовых проблем хватает, достаточно сказать что в ядре linux есть отдельный список для обхода ошибок в прошивках: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n3999
Неа, нет там второго чипа, он же денег стоит. Один и тот же TLC и есть. Фокус в том, как именно пишется ячейка TLC или QLC — нетривиально она пишется. При этом есть возможность в ячейку TLC записать только 1 бит данных вместо 3 (4 у QLC) затратив на это заметно меньше времени. Поэтому в часть свободных ячеек можно писать со скоростью повыше. Это маркетинг нынче и называет SLC кэшом. Именно потому такому кэшу и становится грустно, когда накопитель оказывается заполнен ближе к заявленной ёмкости — уже нет достаточного числа свободных ячеек куда можно писать только 1 бит из положенных 3.
Так практически все десктопные модели делают, за очень-очень редким исключением. Разница в том, что происходит после исчерпания кэша быстрой записи, да. Кто-то замедляется в пару раз без явных перекосов отзывчивости до ещё приличных значений сильно выше HDD, а кто-то начинает страдать.
Тогда с той же самой степенью обоснования заявляем, что «обычный ssd» © вместо умирания переходит в read-only и вообще не требует услуг лаборатории, просто копируете данные на другой. А что? По статистике моей берлоги так и получится: из всех трупиков HDD лишь один предупредил о проблеме в SMART заранее, зато абсолютно все дохлые SSD (один) перешли в read-only и не препятствовали извлечению оставшихся данных.
Можете на уровне культа доверять HDD и верить что за весьма нескромный ценник вам поможет лаборатория, ваше право. Или ещё какому накопителю. Кто-то в надёжность DVD верит, кто-то ещё во что-то.
Но если данные важны — резервной копией озаботиться придётся. Как минимум одной. Это не опция, а необходимость. Либо на самом деле эти данные были не нужны.
Да, это проблема нашей цивилизации вообще как таковой, у человечества нет технологии надёжного сохранения данных.
Да, совершенно верно, отдельная группа HDD, выделенных монопольно под WAL — это именно что «исчезающе уникальное явление», иначе не сказать. Когда-то давно, когда сотня гигов места на SSD было очень дорого, такое практиковалось и было хорошей идеей. Но сейчас HDD уже слишком медлительны даже чисто под WAL. Критичное здесь опять же: во-первых latency на несколько порядков выше SSD, а значит каждый коммит выполняется медленнее, во-вторых — в принципе предел по скорости последовательной записи. Базе писать WAL со скоростью в сотню-другую мегабайт в секунду не так сложно как может показаться. А вот механика начинает захлёбываться от такого счастья. Добавлять ещё шпинделей? Но зачем страдать?
Вот про видеонаблюдение я не компетентен, согласен.
Фраза так построена, будто предполагает вообще наличие возможности оставить механику в таком месте.
Да ничего подобного. Недорогие Read Intensive SSD плохо годятся для интенсивной записи, это верно, но нюанс в том, что там где есть интенсивный IO — механике делать вообще давно уже нечего. Уровни производительности даже дешёвых SSD давно уже недостижимы для HDD. Даже если у вас будут сотни шпинделей — разницу в латентности на несколько порядков вы так не компенсируете.
Единственный оптимальных сценарий нагрузки HDD — последовательное чтение или запись одним потоком — слишком уникален и не встречается в реальности. Но SMR диски и этот сценарий старательно хоронят.