Возьми TempleOS. Летать будет, без базара говорю. https://www.youtube.com/watch?v=8ZawwsFMHB0

Возьми TempleOS

религия не позволяет

В ассемблер не веришь?

Что-то ты не договариваешь.
У меня Plasma5 и норм пляшет на 2-х ГБ. Ставь Oper-у новую. Она объективно шустрее firefox. попробуй в параметры ядра поставить

elevator=cfq nohz=on

❯ cat /etc/sysctl.d/50-dirty.conf 
vm.dirty_bytes = 66554432
vm.dirty_background_bytes = 33554432

Ограничивает размер writeback-кэша до 64 мегабайт для активных и 32 мегабайт для фоновых задач соответственно. Линукс будет чаще сбрасывать «грязные» страницы на диск, не давая им накопиться в огромных количествах в памяти и уронить систему в I/O-кому. В твоём случае должно быть особенно актуально, ибо запись торрентов на диск.

Какой ж/д? Вместо генту могу предложить slackware

Тормозит в основном при скачивании торрентов и копировании файлов. Ну и при открытии кучи вкладок в браузере, но оно и понятно — 2гб ОЗУ.

Не качай много по торренту. Не копируй много файлов одновременно. Не открывай кучу вкладок одновременно.

А эти службы при отключении никак не повлияют на производительность.

Генту не предлагать ))

Calculate, Funtoo.

Просто мысль: а как насчет попробовать FreeBSD? У неё же свой собственный сетевой стек и совсем нет 12309.

Calculate Linux Desktop MATE

Уменьши vm.dirty_bytes и vm.dirty_background_bytes как уже сказали.

SSD и перекатиться на Devuan. Если /home отдельным разделом, то переезд вполне комфортнен.

Zram

Btrfs со сжатием, это ускорит запись на диск

Высоким I/O можно диск убить, особенно торрентами. Конкретно под торренты лучше использовать качалку которая как можно реже будет сбрасывать на диск (например порциями по 300MB) и практически не раздавать ничего.
Если материнская плата позволяет, то всеми правдами и неправдами докупить 8gb ram. Это в конце концов линукс, тут испокон веков, любили ОЗУ.
Ну, а если нет, то не открывать кучу вкладок в браузере, не качать много торрентов за раз.

перекатиться на Devuan

По-моему, его делали прибалтийские наркоманы. Релиз, основанный на Jessie выпустили, когда уже Stretch почти вышел. Они 2 года systemd выпиливали? И разве systemd как-то влияет на производительность?

Btrfs со сжатием, это ускорит запись на диск.

А производительность в целом увеличивает? И не нагружает ли ЦП?

ЦП конечно нагрузит, но сжатие можно отрегулировать, фишка в том, что на медленном диске быстрее сжать и записать, чем просто записать, то же с чтением

Кроме того btrfs имеет много настроек позволяющих ее ускорить

Недостатки - не очень надежна

В тестинге софт свежий.

есть такой пакет preload который якобы ускоряет работу системы, но у меня он почему то ничего не ускорил...

Если у ТС HDD, то не убьет.

Btrfs — copy-on-write. Если у тебя HDD, то от CoW на торрентах станет только хуже. CoW можно отключить для отдельных файлов/директорий, но (ЕМНИП) вместе с отключением CoW btrfs отключает ещё и контрольные суммы со сжатием. И это, уже сжатый медиа-контент (музыка, видео) очень плохо жмётся «повторно».

Убьёт, кеширование записи на диск не просто так придумали.

А уж если у ТС'а что-нибудь уровня WD Green, то тут уж это просто вопрос времени (ну и удачи).

Мне приходилось и на гринах и синьках обжигаться. Для торрентов либо RE, либо мудрить с кешами и ОЗУ.

Какого года выпуска был WD Green? У меня один живёт с 2009-2010. Всё это время нещадно качаю (и раздаю) торренты — показания SMART в порядке, проблем с ним не наблюдаю. А вот на свежие (2012 и позднее) все, кого знаю, ругаются.

2014 года. Их скорее всего по ресурсу и материалам заточили на меньшие нагрузки, вот и всё. В любом случае торренты это частые рандомные обращения к HDD.

pf-kernel зачастую устранял 12309, но лучший способ — перейти на *BSD.

И разве systemd как-то влияет на производительность?

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

Ща набегут и начнут лопатами махать

У неё же свой собственный сетевой стек и совсем нет 12309.

Тут как бы для начала нужно выяснить из-за чего появляются тормоза - нехватка ОЗУ, мощность процессора, либо медленный HDD

И да, советую отказаться от zswap в пользу zram, так как он поможет снизить обращения к диску, отдав для него 75% ОЗУ. Попробуй такой скрипт:

#!/bin/bash
RAM_PERCENT=75

NUMCPU=`ls -1 -d /dev/cpu/? | wc -l`
RAM=$((`cat /proc/meminfo | grep MemTotal | sed 's% %%g' | sed 's%kB%%g' | cut -d':' -f2`/1024))
ZRAM=$(($RAM*$RAM_PERCENT/100))
ZRAM_DEV_SIZE=$(($ZRAM/$NUMCPU))
echo "Total RAM:                        $RAM MB"
echo "Total size of zram:               $ZRAM MB"
echo "Num of zram devices:              $NUMCPU"
echo "Size of each zram device: $ZRAM_DEV_SIZE MB"


modprobe zram num_devices=$NUMCPU

ls -1 -d /sys/block/zram* |
while read i
do
      echo $(($ZRAM_DEV_SIZE*1024*1024)) > $i/disksize
done

ls -1 -d /dev/zram* |
while read n
do
      mkswap $n
      swapon $n -p 10 -d

Zram лучше тупо потому, что все ядра проца использует. И ещё под memory pressure стабильнее себя ведёт.

num_devices

А вот это не нужно, он и так все ядра использует.

Не должно тормозить. У меня даже PIII c 256 мб, при аналогичном использовании, но без современного веб не тормозит, даже с IDE HDD.
Торренты могут тормозить из-за большого количества открытых соединений, можешь настроить, это уменьшит нагрузку на CPU.

vm.swappiness=20

Это на вкус, но я бы оставил 40 или дефолтные 60, потому-что чем у тебя компьютер слабей тем больше дефолтные значения актуальны. Я наоборот чем больше памяти, тем меньше ставлю swappiness. Тебе же так у тебя небольшое количество RAM, наоборот лучше выгрузить что-то наименее нужное в swap.
Вот только у тебя тут вполне еще, не труп.
Что за HDD, что за CPU?

zram лучше потому, что создает сжатый раздел swap внутри ОЗУ, в отличие от zswap, который создает сжимает раздел swap на диске и тем самым уменьшает IO

num_devices нужен для создания нескольких виртуальных swap разделов (равное количеству процессорных ядер), что позволяет данным, отправляемым в swap не стоять в очереди, а писаться параллельно в каждый раздел

Zswap тоже в реальности в реальный своп практически не пишет. num_devices не нужен, zram и так использует все ядра, открой уже документацию.

По своему опыту — на системе с ОЗУ 1.5GB при свопе в zram chromium нередко выдавал Oops!

С zswap такого не наблюдалось.

Может ещё от настроек зависит, в какие диапазоны попадают в зависимости от физичиских объёмов дефолтные заданые в процентах значения.

а зачем на старое железо ставить новейшую версию линукса? Старый дэбиан будет быстрее работать. Это то же самое если на пентиум 3 поставить шиндоус 10

Вендузные предрассудки. Самый новый lfs/гента/арч уделают твой старый дебиан.

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

я знаю, что zram использует все ядра при компрессии.

тут https://www.kernel.org/doc/Documentation/blockdev/zram.txt сказано:

2) Set max number of compression streams
Regardless the value passed to this attribute, ZRAM will always
allocate multiple compression streams - one per online CPUs - thus
allowing several concurrent compression operations. The number of
allocated compression streams goes down when some of the CPUs
become offline. There is no single-compression-stream mode anymore,
unless you are running a UP system or has only 1 CPU online.
To find out how many streams are currently available:
cat /sys/block/zram0/max_comp_streams

Что, повторюсь, является числом параллельных потоков сжатия. Однако, это не влияет на работу самого Linux со swap. Более того, документация к swapon говорит:

Calls to swapon normally occur in the system boot scripts making all swap devices available, so that the paging and swapping activity is interleaved across several devices and files.

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

Испытывал проблемы с zram на ядрах 3.2. Тут тред создавал: Есть ли истории успеха использования zram? но там я ловил полное зависание. С тех пор проблем с ним не имею - использую везде

Не вывод, а предположение. Ну да ладно.

Никак, Еxt вообще сама по себе жалкое поделие и костыль, для торрентов вообще не предназначена, и 12309 идёт вообще не от ядра, а именно от всратой ФС. Уверен, этот коммент будет удалён, ибо эта проблема всячески скрывается.

Еxt вообще сама по себе жалкое поделие и костыль

Тогда почему она в большинстве дистрибутивов по умолчанию?

ибо эта проблема всячески скрывается

Масонами, рептилоидами, англосаксами, колдунами-учёными? То есть, разработчики дистрибутивов и админы ЛОРа с ними в сговоре?

Перейти на KDE3, выключить Dbus, проверить чтобы в памяти не было Python (ps -a | grep python).

Because Linux sucks!

Для болезных в линуксе есть ещё куча фс, включая вендовые, и на них тот же самый 12309, идиотик.

MuQSS

Вилами же.

Не качай много по торренту. Не копируй много файлов одновременно. Не открывай кучу вкладок одновременно.

Я б добавил еще:

Не пользуйся вообще линуксом.

Вместо тысячи слов =)

Поддерживаю совет про FreeBSD из-за ZFS.

Тормозит в основном при скачивании торрентов и копировании файлов.

Не совсем понятно при чём здесь количество свободной оперативной памяти.