Армянское Радио

Ведь опытные программисты укладываются в набор команд 8086

Нет. Лет 30 уже никто не пытается уложиться в 8086. Наоборот, если уж берутся писать на ассемблере, то часто с целью использования каких-то железо-зависимых вещей.

Как и программы на Си, программы на Ассемблере нужно пересобирать под каждую следующую платформу. Разве нет?

Что вы вкладываете в слова "новая платформа"?
Другая ОС? - да, надо пересобирать, и часто менять, ведь API разных ОС отличается. При этом C часто позволяет исходный код программы не трогать, т.к. функции стандартной библиотеки, POSIX API предоставляют платформонезависимый интерфейс. А вот в программе на asm соответствующий код придется переписать.

Новая версия ОС? - здесь есть свои нюансы, но собранная статически программа обычно прекрасно работает на протяжении многих поколений ОС (вы же не загружаете новую версию, допустим, игры под каждую версию Windows? Взять вон diablo 2 - как работала она под Win 98, так же отлично тот же бинарник заведется в Win 10).

Новый процессор? - эти вообще паталогически обратно совместимы. Код, написанный или скомпилированный чисто под 30-летний 386 будет работать на i9 (при условии совместимости по пунктам выше).

Возвращаясь к первоначальному вопросу: вы, видимо, не понимаете или не придаете значения тому, что существуют не только x86 процессоры. Изначально ЯП высокого уровня разрабатывались именно с целью абстагировать код программы от конкретного железа. В 60-80-е годы не было единой и даже какой-то одной распространенной железной платформы, что же прикажете, допустим, стандартные утилиты Unix переписывать каждый раз с начала и до конца на новом (подчеркну, НОВОМ, другом) ассемблере?
Даже сейчас, когда вроде бы кругом x86, есть Itanium (ну ок, был в недавнем прошлом), ARM (в виде нескольких версий архитектуры и огромном количестве железных воплощений), где-то теплятся SPARC и PowerISA. Наконец, микроконтроллеры (привет ардуинщикам).

Коротко: ЯП высокого уровня (не только C) позволяются абстагироваться (до определенных пределов) от железа и от ОС и не менять исходный код программ при переносе на другую платформу, ограничиваясь механической процедурой перекомпиляции.

Потому что nextcloud в ubuntu установленный через snap - тормоз коих еще поискать надо

ставьте всегда руками на стэк nginx+php-fpm+mysql(желательнее вообще postgresql)+memcached(или redis)

Ну для начала надо определить что значит маленькая скорость, и что ее ограничивает.
Канал у вас 1гигабит.
Значит теоретически по нему можно прокачать в районе 120мегабайт/с.
Практически меньше - зависит от настроек сети, типа трафика, используемых протоколов.
К тому же канал может быть загружен.
В общем нормальная скорость передачи в среднем для гигабитного канала это 50-60мб/сек.
Ваши значения вроде такие и есть.

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

Поэтому определите какая скорость вам нужна, насколько реальная отличается от нужной.
И тогда уже можно думать что именно стоит сделать.

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