Melkij

При построении crossfire доступна память только одной карты. Используются обе, но информация в них дублирована. Давняя проблема multiGPU конфигов.

Второй слот: у вас даже если и присутствуют контакты в слоте физически - этот слот подключен к южному мосту через PCI-E 2.0 x4. Для тех GPU, из которых имеет смысл городить multigpu, а не осмысленнее взять карту уровнем выше и не страдать от отсутствия поддержки multigpu в играх - это бутылочное горлышко. Основной слот PCI-E x16 даёт пропускную способность в 4-8 раз выше (в зависимости от вставленного сокет CPU - слот подключен напрямую к CPU и тот определяет версию шины). Как думаете, что происходит при таком дисбалансе пропускной способности? CF реализован просто для галочки.
Но отличная вещь для втыкания какого-нибудь рейд-контроллера PCI-E х4 или х8, или ещё чего-нибудь, чему мало х1 слота.

По майнерам не подскажу.

Софтовый рейд вас не ограничивает глупостями вроде 1 диск может быть только в одном массиве. Можно разделы одного диска объединять в разные массивы.
Пилить диски можно как угодно. Например, распилить 3тб диски каждый на два раздела: по 1 и по 2тб каждый. Собрать в итоге два raid5: 3 тома по 1тб и три по 2тб. Итого 6тб форматированной ёмкости, допустимо выпадение любого диска массива. При необходимости в едином куске места - поверх этого развернуть LVM.
Наращивать можно дисками любого размера, условие одно: добавляемый том не меньше используемого размера тома в действующем массиве.

Про raid5 в домашних NAS - у меня два диска разом за 8 лет не умирало. Дефолтно в debian включен кроновый скрипт верификации всех софтовых рейдов раз в месяц. Пару дисков проблемных он и обнаружил заблаговременно.
Но вот два диска разом выпасть из массива - это было. Кабель питания отошёл. Собрать обратно массив удалось, а вот ФС побилась. Но у меня был бекап, потеряны только неважные данные.

Если нет никакой возможности использовать географически-удалённое место для бекапа, то для бекапа можно выделить области на этих дисках. Только не в составе чего-то сложного (lvm, raid) и не на том же диске, где лежит основная копия! Можно использовать raid1 при необходимости продолжать работу при отказе диска - зеркало хоть восстанавливать просто и достаточно одного любого диска.
Например, порезать 3тб диски на два раздела: 2тб и 1 тб. Затем собрать raid5 на трёх 2тб томах - под всякое не очень нужное. Три раздела по 1 тб - под важные данные. Можно собрать raid1 из двух дисков. Но не как зеркало из всех 3 дисков! Это только от физической поломки поможет, а от проблемы с ФС - уже нет. Один раздел не должен быть примонтирован постоянно, монтируется только на время бекапа основной части. rsync в кроне как самый простой вариант. Лучше бы, как уже советовали, 3 независимых тома: актуальная копия, горячий регулярный бекап, последний диск под холодный бекап, его физически отключать (можно сколхозить автоматический девайс для размыкания цепей на твердотельных реле).

swap в наличии. Так что описываемое поведение вполне норма, когда начинает подходить к концу свободная памяти и ОС лезет в swap (что можно проконтролировать вызовом free при начале проблем). Немного странно выглядят падения расширений, но, возможно, их отстреливает хром за слишком долгий отклик.
Для начала стоит покрутить swappiness, чтобы ОС лезла в свап только в крайнем случае.
Затем поиграть в Zswap, zram. Что порежет производительность CPU, но поможет от нехватка памяти.

Раз на всё памяти не хватает - то есть варианты действий:
- отчаянно тормозить в свапе
- звать на помощь OOM killer, который будет убивать какой-нибудь на его усмотрение бесполезный процесс. Для этого достаточно вырубить swap и ядро само позовёт при необходимости.
- добавлять память
- уменьшать потребление памяти. Следить, кто сколько памяти жрёт, может у вас кто-нибудь не особо нужный просто течёт по памяти. Можно запускать текущие процессы в cgroup с жёстким лимитом памяти, тогда они будутт отстреливаться при превышении лимита.

правильно ли я понимаю, что mysql кэширует не сам запрос, а как бы схему его выполнения?

Нет, mysql как раз кеширует непосредственно результат конкретного запроса.
План запроса строится заново для каждого запроса, не найденного в query cache.
query cache может быть и выключен, тогда mysql от запроса не кеширует ни план, ни результат.

Если запрос выполняется к редкоиспользуемой части данных - значит скорей всего пришлось читать с диска. Это варьируется от медленно до смертельно медленно в зависимости от дисков. Затем данные будут жить в кеше данных mysql (см. тюнинг используемых storage engine) и в кеше операционной системы (плюс в query cache результат запроса), пока не будут оттуда вытеснены другими более нужными данными. Сами индексы тоже могут выгружаться из памяти и даже index only scan может пойти на медленный диск.
Запрос, которому пришлось лезть на диск и запрос, все данные для которого уже оказались в памяти - две огромные разницы даже для приличных SSD.

Давно удалённая функция mysql_query попытается сначала найти уже открытое ранее соединение через mysql_connect. Если такого нет - попробует сама установить соединение с дефолтными настройками root@localhost,, без пароля.
Что в тексте ошибки и видно.

А смысл?
Чтобы подключиться к базе, надо знать действительные логин/пароль. Значит код расшифровки будет здесь же доступен.
Если к базе подключаться не надо - то и конфига здесь не будет.

Официально да. Интел уже давно занижает официальные режимы работы контроллера памяти. Заявленные режимы памяти, поддерживаемые матплатой - работать будут.

https://habrahabr.ru/post/312900/
К сожалению, пока потребуется отдельная видеокарта для каждого места.

Реально. А в чём проблема? Самое просто - завернуть порты pop/imap/smtp, можно даже не прикручивать проверку, на каких нынче адресах почта живёт, а любую почту через этого провайдера пустить.