Daemon23RUS

есть черепичный диск SMR wd red, планировал под Рейд 1

Черепичные диски лучше не ставить в RAID. Чем сложнее массив, и "умнее" устройство / контроллер / система, тем выше вероятность, что такой диск ей не понравится, даже будучи исправным, либо выскочат какие-либо глюки.
Домашний РЭЙД 1, конечно, сильно проще, вероятность проблем с СМР ниже, но я бы всё равно воздержался, тем более у вас есть возможность - много других дисков.

В теории вроде бы черепичные диски слабы в записи, а на чтение вроде бы должны

У нас есть достаточно подробная статья про SMR HDD с графиками и подробностями. Вы - молодец, думаете вместо того, чтобы пользоваться бездумно, посмотрите - там есть и раздел "Особенности эксплуатации".

Но нет ли у них бо́льшей нагрузки при чтении случайных данных из-за специфичной записи?

Именно со чтением особенных проблем быть не должно, но это именно со чтением. Я бы не исключал даже возможное наличие плюсов из-за того, что формально в ленты укладываются данные, записанные в определённое время. Т.е. для файлов (не для баз данных) возникает некое подобие дефрагментации, особенно, если их потом не трогать.
Однако, алгоритмы SMR закрыты и различаются, так что гарантий тут никаких.

Чтение может просесть, если винчестер одновременно со чтением будет "тасовать" ленты. Тут вообще возможно всё, вплоть до выхода диска из строя из-за багов прошивки (редко, но тоже бывает).

единственный жёсткий диск, который резко сломался, был как раз черепичный ... (правда, он с 2020 г был жёлтый и имел 10000+ переназначенных секторов

Это отличная шутка на тему неожиданного выхода харда из строя :)

Затрудняюсь даже представить как вы опишете поломку SSD, которые как раз-таки умирают действительно внезапно :)

Никак. Перестать заниматься ерундой и строить из себя школьного хацкера.

ноут без таблетки биоса и без батареи(сдохла и я не доставал ещё)

Собственно вот и причина. Тут либо извлечь батарею и пробовать включить от подключённой зарядки - если заработает, то так и оставить. А если не заработает - значит нужна новая батарея. Зависит от реализации схемы питания ноута. В ноунеймах может быть всё что угодно.

таблетку не знаю какую покупать(так как модель ноута почти ноунейм)

Разбираете, смотрите какая нужна батарейка, покупаете и ставите. Либо просто приносите в любой СЦ с просьбой о замене батарейки CMOS. Там обычно что-то типа 2025/2032/2042, реже что-то типа 1220/1620 и т.п. Если батарейки вообще нету и нет для неё отсека/разъёма - значит ноут использует свою батарею для хранения настроек биоса.

То, что вам нужно называется "Встряхивание дерева (Tree-shaking)". В популярных сборщиках есть либо из коробки либо в плагинах. Например в rollupjs и webpack эта фича есть из коробки:

• https://rollupjs.org/faqs/#what-is-tree-shaking
  
• https://webpack.js.org/guides/tree-shaking/
  

# Разрешаем "исключения" без редиректа
iptables -t nat -A PREROUTING -p tcp -s 109.194.11.11 --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -s 178.218.22.22 --dport 443 -j ACCEPT

# Всё остальное перенаправляем на 4433
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 4433

В фазе vacuuming indexes нам нужно прочитать и обработать все индексы таблицы. Наступает эта фаза всякий раз когда набирается num_dead_tuples столько, сколько уже не лезет в max_dead_tuples (который, в свою очередь, считается от maintenance_work_mem, но для pg15 это по-прежнему не более 1гб, 178956969 как раз похоже на 1гб списка таплов)
index_vacuum_count - это как раз и есть счётчик, сколько раз вызывали vacuuming indexes. За четверо суток 61 раз vacuuming indexes, то есть не более 1,5 часа каждый - вполне неплохо, бывало веселее, когда каждый vacuuming indexes длился часов по 15.

Начиная с pg13 vacuum (но не autovacuum) может запускать дополнительных воркеров для vacuuming indexes. Применимы max_parallel_maintenance_workers (до тех пор пока позволяют max_parallel_workers и max_worker_processes). Воркеры работают по принципу очереди из списка индексов, в пределе можно запустить воркеров по числу индексов.

Раз досчитали до index_vacuum_count = 61, значит уже прожевали порядка 11млрд мёртвых строк. Похоже что недавно было массовое удаление старых/более ненужных данных. Ну или не менее массовый update, который, конечно, тоже оставит много мёртвых строк.