LinuxMint.com.ru

Когда Transmission работает - сделать ничего не возможно - реакции на клики и энтер долгие, думает комп долго, и это и как в этой проге, так и в файл-менеджере (и аналогичных). Лечится как ни будь?

Cahes писал(а): ↑

22 дек 2017, 15:24

и это и как в этой проге, так и в файл-менеджере (и аналогичных).

Может всё дело в производительности железа? О нем ведь ничего не сказано и остается только гадать...

Cahes писал(а): ↑

22 дек 2017, 15:24

Когда Transmission работает - сделать ничего не возможно - реакции на клики и энтер долгие, думает комп долго, и это и как в этой проге, так и в файл-менеджере (и аналогичных). Лечится как ни будь?

У меня похожее было - перешел на Deluge и стало лучше (по данным top). Хотя это субъективно, может зависеть от конкретного компьютера.

У меня с Transmission всё нормуль. Правда последнее время пользуюсь qBitTorrent. Разрекламировали блин Но переход никак не связан с производительностью. Оперативы 8 гигов.

Dja писал(а): ↑

22 дек 2017, 15:44

железа? О нем ведь ничего не сказано...

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

У меня Intel3 и 4 гига памяти. При чём здесь железо - если всё остальное летает, как я и указал в стартопике.

Cahes писал(а): ↑

22 дек 2017, 17:18

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

Ваша подпись по данному вопросу бесполезна чуть менее чем полностью. Вывод inxi -Fxz является минимальной отправной точкой. А лучше сделайте hw-probe, и вот ссылку на его результат вставьте в подпись. Это будет по настоящему полезно.

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

Там может быть еще с дисками узкое место. От FS и планировщика IO тоже сильно зависит. И от настроек дисковых буферов самого transmission. По умолчанию они плохо подходят для широких каналов.

Да, есть такое. При скачивании файла большого объема, Transmission интенсивно начинает кушать swap. Проблему решил установив Qbittorrent.

Cahes писал(а): ↑

22 дек 2017, 15:24

Когда Transmission работает - сделать ничего не возможно - реакции на клики и энтер долгие, думает комп долго, и это и как в этой проге, так и в файл-менеджере (и аналогичных). Лечится как ни будь?

Да вообще то это нормальное явление особенно если раздаётся большое количество файлов. Идёт немалая нагрузка на процессор, интенсивное обращение к жёсткому диску, интернет канал практически полностью забивается. Тут либо дать возможность компу возможность постоять на раздаче а самому прогуляться или отключить раздачу и спокойно пользоваться компом. Можно конечно поставить ограничение на количество раздаваемого но торможение всё равно будет ощущаться.

slant писал(а): ↑

22 дек 2017, 17:28

лучше сделайте hw-probe, и вот ссылку на его результат вставьте в подпись.

Сдедал.

Chocobo писал(а): ↑

22 дек 2017, 17:28

понаблюдай за его прожорливостью в том же top / htop

Очень важно - HTop или базовый монитор? В мониторе показывает ЦП - ноль, а памяти 50 метров.

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

slant писал(а): ↑

22 дек 2017, 17:31

с дисками узкое место. От FS и планировщика IO тоже сильно зависит. И от настроек дисковых буферов самого transmission.

Надо понимать - на это не стоит обращать внимания - грузить всю систему это не должно.

Я установил себе другие клиенты - сравню. Но заинтересовал ваш подход через анализ железа (чисто из интереса развития) - что умного можно выудить для нашего случая?

Cahes писал(а): ↑

22 дек 2017, 15:24

Когда Transmission работает - сделать ничего не возможно - реакции на клики и энтер долгие, думает комп долго, и это и как в этой проге, так и в файл-менеджере (и аналогичных). Лечится как ни будь?

А как разбит HDD? Надеюсь скачка не стекает в ntfs раздел?

Cahes писал(а): ↑

24 дек 2017, 09:31

Надо понимать - на это не стоит обращать внимания - грузить всю систему это не должно.

Еще как может. Правда, судя по hw-probe - это скорее всего не ваш случай. Не те условия.

Cahes писал(а): ↑

24 дек 2017, 09:31

Я установил себе другие клиенты - сравню. Но заинтересовал ваш подход через анализ железа (чисто из интереса развития) - что умного можно выудить для нашего случая?

Много чего. Во первых - видя точный конфиг можно исключить нехватку ресурсов. Т.к. можно увидеть как используется память, как разбиты диски, как смонтированы разделы (режимы и опции), какая FS какое наполнение. В том числе - наличие swap в виде файла a не раздела. Это все может влиять при разных условиях.

Судя по тому, что у вас в мониторе нагрузка ЦП - 0 (это во время тормозов?) - возможны проблемы с IO Wait. Если тут виноват transmission, можно сделать так: идете в настройки программы, и выставляете объем дискового кеша не менее 100MB. (у меня обычно 300МБ стоит).

А чтобы разобраться, где именно в в системе "узкое место", хорошо помогает утилита atop. Ставите ее: apt install atop, потом просто запускаете из консоли во время тормозов. Она покажет где нагрузка. Если хотите помощи с интерпретацией - сделайте скриншот консоли или запустите таким образом:
atop 10 2 > log.txt
Команда будет выполнятся ~20 секунд. И файлик который получится (log.txt) - сюда пожалуйста.

vir0id писал(а): ↑

24 дек 2017, 13:40

Надеюсь скачка не стекает в ntfs раздел?

А что такого? У меня файлопомойка на ntfs. Даже в хомяк папки с документами, картинками и прочим смонтированы в аналоги с ntfs раздела. Никаких проблем нет. (даже когда пользовался Transmission).

Dja писал(а): ↑

16 фев 2018, 16:20

А что такого?

У меня частенько наблюдался, раньше, похожего рода инцендент при скачке в ntfs раздел. Трансмишену было трудно туда сливать. Он наргужал мне проц и в последствии система висла. Я спросил, исходя из своего решения. А решение у меня было простое - сменить путь слива в другой раздел с фс ext3.