АртемЪ

Если в Windows 10 более чем один сетевой интерфейс, как система с ними работает?

Очень просто - на адреса для которых явно прописан маршрут пакеты пойдут через интерфейс указанный в маршруте, если маршрут явно не прописан для конкретного адреса, то пакет пойдет через интерфейс указанный как шлюз по умолчанию.

Как объединить два интерфейса в один?

На одном компьютере? Никак!

То есть использовать суммарную скорость обоих интерфейсов?

Если на одном компьютере - единственный вариант маршрутами отправлять данные на разные адреса через разные интерфейсы.
Например маршрут на адрес сайта А через интерфейс 1, а маршрут на сайт Б через интерфейс два. В результате при скачивании файлов с этих сайтов будет использоваться оба интерфейса.
Но прописывать адреса руками то еще удовольствие.

Если делать это на шлюзе сети - можно отправлять разных пользователей сети через разные интерфейсы - пользователь с компьютера А качает файлы через интерфейс 1, пользователь с компьютера Б качает файлы через интерфейс два.
Так же можно устроить роунд робин - каждый новый запрос кидать в новый интерфейс по очереди.
Первый запрос в первый интерфейс, второй запрос во второй, третий запрос в первый, и.т.д.
Вот только проблема - работать так будет стабильно только торрент, а на сайтах будет слетать авторизация из- за того что запросы будут приходить с разных адресов. В принципе на хорошем роутере эту проблему можно решить путем маркировки трафика, отправляя запросы одной сессии через один интерфейс, но это непросто, ресурсоемко, и это решит не все проблемы.

Возможно ли использовать два и более интерфейса для того чтобы скачать один большой файл?

Через торрент - да, такое можно соорудить. Если качаете файл с одного сервера с авторизацией не получится.

То есть использовать суммарную скорость обоих интерфейсов?

В принципе можно, но нужен внешний сервер для этих целей.
И далеко не факт что суммарная скорость двух интерфейсов будет больше чем скорость одного из них. В лучшем случае она будет чуть больше чем скорость самого быстрого. В худшем на уровне самого медленного.

Для скачивания одного файла одним пользователем будет примерно так-

• Если у вас каналы одинаковые по характеристикам например два стабильных проводных канала по 100мегабит - вполне реально получить 150мегабит в итоге.
  
• Если у вас разные стабильные каналы, например два проводных канала по 50 и 100мегабит, то в сумме сложно будет получить более 100мегабит.
  
• Если у вас один стабильный проводной и один Wifi - суммарная будет равна или немного выше чем скорость самого медленного.
  

Wear_Leveling_Count не самый надежный параметр, все их считают по разному, и зачастую он то обнуляется, то вообще погоду показывает.
Смотрите на Total_LBAs_Written, судя по нему записано на оба диска по 50тб, разница в записи 300гб.
В принципе такое расхождение может быть вызвано тем что TRIM не доходит до одного из дисков.
Хотя если у вас сервер, то лучше бы не полагаться на трим, а оставить приличный over provisioning.

Как определить, когда пора менять проблемный диск?

Ориентируйтесь по Total_LBAs_Written и отслеживайте нездоровые движения по Reallocated_Sector, Used_Rsvd_Blk_Cnt_Tot, Erase_Fail_Count_Total

Если опыта не было и хотите покрутить, то надо искать более конкретные вещи.
Т.е не установку LEMP вообще, ибо там очень обширная тема, и много разных заморочек.
Надо начать с чего то одного, допустим разобраться как настраивать LEMP скажем для проекта на Django (ну или с чем в основном предполагаете работать) так будет понятнее, удобнее и практичнее.

Лежит вроде.
Пока неизвестно что вроде валить некуда, может он просто по техническим причинам лежит.
Заработал.

8gb ОЗУ, двух ядерный процессор AMD с частотой в 3Ghz и жесткий диск на 1tb.

Это нормальная конфигурация для секретаря работающего с браузером и офисом.
Хотя сервер терминалов на пять юзеров, если без фанатичных требований к скорости вполне потянет.
Если на лицензии пофиг - вполне себе вариант.

Никак.
Потребление памяти определяется самой программой, способ запуска на это никак не влияет.

Слышал что можно сделать раздел в оперативной памяти, а в нем раздел имитации жесткого диска и запускать оттуда,

Это как раз способ уменьшить объем доступной памяти.

Пару часов точно продержится.
Нужна действительно длительная работа? - Возьмите повербанк.

На самом деле все просто -
SSD быстрый, но небольшой - на него нужно размещать информацию к которой критичен быстрый доступ, и ту информацию которая активно читается, пишется.

HDD медленный, и большой - на него нужно размещать информацию к которой некритичен быстрый доступ, или ту которая редко читается, пишется

В общем выносите на HDD архивы, коллекции семейных фотографий, папку в которой хранятся все сериии санта-барбары, и.т.п. А остальное по возможности на SSD.

В идеале - все на SSD, за исключением поддиректорий в /home хранящих тяжелые и редкоизменяемые данные.
Если все не влазит то
обязательно на SSD \temp, \var, swap
Остальное как влезет.

Это нормально.
Уперлись в деградацию скорости записи.
Поскольку TRIM в ваших условиях работать не будет да и если бы работал толку от него ноль, то нужно обходиться без него.

Over provisioning спасет ситуацию

Во первых TRIM это команда, если трим включен, это значит что команда отправляется, но не значит что доходит.
Во вторых TRIM в большинстве случаев не проходит через различные виртуальные прослойки вроде рэйдов, lvm, и прочего
И самое главное в вашей ситуации даже работающий TRIM будет бесполезен.

Нужен over provisioning приличного размера - не менее чем размер одной непрерывной записи.
Т.е если часто записываете на диск большой объем информации например 50гб, то нужно чтобы размер over provisioning был более 50гб.