rtorrent грузит процессор, низкая скорость на отдачу

Конфигурация - симметричный канал в мир на 3Мбит, роутер D-Link DIR-300/NRU, проброс портов и т.д. Ноутбук с 6ГБ оперативки, система установлена на SSD, торренты находятся на внешнем 2.5" винте. Торрентов чуть меньше сотни, раздачи средней популярности, бОльшая часть с известного российского трекера :)

Пользуюсь transmission-gtk, напрягают фризы - интерфейс трансмиссии постоянно подвисет на 1-10 секунд. За сутки сидирования раздается 4-5ГБайт. Ограничение по скорости раздачи не замечал, всё упирается в канал. Вот перед глазами 150КБайт/с на отдачу. transmission-qt выглядит чудовищно (у меня), но интерфейс почти не фризится.

Решил заюзать почитаемый многими rtorrent.
Первое - раздает меньше (порядка 2ГБайт в сутки на импортированных из трансмишена торрент-файлах). Скорость выше 80КБайт/с не поднимается.
Второе - грузит проц. В top каждые 5-20 секунд наблюдается “всплеск” процессорной активности, 1-5 секунд 100% процессора занимает rtorrent. Оставил на ночь сидировать, утром ноутбук ощутимо теплее чем если бы раздавал трансмишен. В цифрах это температуры проца 45-50 и 60-62 градусов соответственно.

gluk ~ $ egrep -v '^($|#)' .rtorrent.rc
system.file_allocate.set = yes
directory = /run/media/gluk/Storage/torrent
session = /home/gluk/.config/rtorrent-session
done_fg_color=7
active_fg_color=1
schedule = low_diskspace,5,60,close_low_diskspace=100M
port_range = 51413-51413
dht = auto
dht_port = 6881
peer_exchange = yes
encryption = allow_incoming,enable_retry,prefer_plaintext

Кто виноват и что делать?
Не процессор он грузит, а жёсткий диск. А процессор нагружается, потому что ввод-вывод в Linux реализован очень плохо. Хоть убейте, но это факт.

Могу посоветовать проверить степень фрагментации тома с раздачами и отключить журналирование там же. Ну или пользоваться Windows.
Грузит именно процессор. Смотрю в top.
Windows не вариант.
Журналирование - да разве оно критично при среднем I/O менее 100кБайт/с? :) В основном фильмы, музыка, т.е. файлы относительно большие.

С фрагментацией ситуация конечно не айс, но мне кажется что проблема не в ней.
 gluk ~ $ sudo fsck -n /dev/sdc4
[sudo] password for gluk:
fsck из util-linux 2.22.1
e2fsck 1.42.6 (21-Sep-2012)
Warning!  /dev/sdc4 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Storage has been mounted 96 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1034457, counted=2567062).
Fix? no
Free inodes count wrong (16169300, counted=16164611).
Fix? no
Storage: 91820/16261120 files (8.9% non-contiguous), 63997991/65032448 blocks
gluk
Free blocks count wrong (1034457, counted=2567062).
Fix? no
Free inodes count wrong (16169300, counted=16164611).
Fix? no

А почему no то?
Да уж, мне тоже интересно вот это Free blocks count wrong

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

man fsck:
-n For some filesystem-specific checkers, the -n option will cause the fs-specific fsck to avoid attempting to repair any problems, but simply report such problems to stdout.
Ну так почему не пустить с -y или просто в ручном режиме без флагов.
Исправил ошибки, сделал дефрагментацию. Поставил на докачку один торрент, остальные раздаются. Раздачи суммарно 8-10 кбайт/с, скачивание на максимальной скорости (300-350 кбайт). Подождал немного…
gluk ~ $ uptime
 06:59:54 up 9 days,  7:20,  3 users,  load average: 0,87, 0,85, 0,96
Дело не в файловой системе.

Как же неохота всплепую искать правильную версию пакета если его поломали… :(
Тогда выкинуть rtorrent.
elsonador
Тогда выкинуть rtorrent.
отличные советы у Вас, то виндовс, то сменить прогу.
 
Зарегистрироваться или войдите чтобы оставить сообщение.