View Full Version : падения rtorrent
опять к наболевшей теме, думаю многим знакомо. Я решил проблему так:
#!/bin/sh
if (expr $(ps -C rtorrent -o %cpu | grep -E '[0-9]') \> 55 > /dev/null 2>&1) then (kill -9 $(ps -C rtorrent -o pid | grep -E '[0-9]');logger 'rtorrent крякнулся +++++++ cpu time limit') fi && sleep 5 && /opt/etc/init.d/S99rtorrent start;
if !(pidof rtorrent > /dev/null 2>&1) then (/opt/etc/init.d/S99rtorrent start;logger 'rtorrent крякнулся +++++++++++++++ down')fi;
то есть понятно: первая часть убивает рторрент, когда он заглючивает и начинает отжирать большое кол-во процессорного времени. Кстати вот еще вопрос: почему в top отображается где-то 95% time cpu, а через команду ps где-то <80 (я в курсе что ps обновляет значения через определенные промежутки времени).
Вторая же проверяет, если процесс и если рторрент "вылетел" запускает вновь. Сие положено в крон и запускается с интервалом 5 минут.
И так проблема:если вводить первую строку в терминале все прекрасно обрабатывается и если рторрент отъедает > 55% времени процессора, как в данном примере, он убивается, пишется сообщение в сис лог и заново запускается, однако через крон это почему-то не срабатывает. Вторая строка работает как надо. В чем дело?
можно было kill -9 $(ps -C rtorrent -o pid | grep -E '[0-9]' заменить на killall -9 rtorrent но это не ощутимо, тк, в принципе одно и то же.
ЗЫ кто-то скажет, что метод плохой. Что ж, как лучше?
Недостатки очевидны: при хэшировании файлов все аналогичные программы начинает кушать камешек и если результат от команды ps будет больше заданного значения - будет ложное срабатывание. Однако хочу заметить, что у меня рторрент в нормальном рабочем состоянии при хэшировании файла не выдавал по команде ps значение более 55. У каждого может быть по-разному - сами смотрите.
uinoksk, спасибо за работу! А поделитесь своими наблюдениями, когда падает rtorrent? Как он себя ведет? При каких условиях? Лично я заметил, что у меня проблемы начинаются, когда на роутере запущены какие-то ресурсоемкие приложения. Просто интересно было бы выяснить истинную причину падения...
Опишу здесь свои наблюдения.
Для начала стоит перечесть проблемы, которые были замечены мной в работе рторрента:
1 В какой-то момент рторрент если смотреть через top забивает процессор под 95% и никак не откликается ни на какие действия ни через морду ни через консоль, само собой ничего не раздается и не качается.
2 Просто процесс сам собой завершается.
Снизить вероятность падения помогло создание на винчестере 3-х разделов: 1 для софта, 2 - для общего хранилища, 3 для закачки. После этого как уже писали уменьшается фрагментация дисков, уменьшается вероятность повреждения в случае если возникнут какие-либо ошибки.
Замечено, что рторрент вылетает чаще\забивает проц, если что-то качается и активно записывается на винчестер.
Учтите что скрипт вверху как я уже писал через крон не всегда срабатывает и может не работать, тк не до конца все отлажено и установлен максимальный лимит в 55% после которого рторрент убивается. Потому иногда если неверно установить значение (сами смотрите как у вас - наблюдайте) могут быть ложные срабатывания и рторрент пытается запуститься, хотя уже работает нормально. В таких случаях вы можете увидеть в сис логе что-то вроде "su: + none admin:p2p"
Замечено, что чем чаще происходит такое ложное срабатывание, тем выше вероятность, что рторрент начнет отъедать под 95% процессорного времени и "зависнет". Очевидно, что при повторном старте программы она автоматически проверяет запущена ли она уже от имени того пользователя, от которого из запускалась (в данном случае p2p), и если 1 копия уже есть в памяти - запуска 2-й копии не происходит, и, если этот момент прошел не так- происходит то-ли ошибка в программе то-ли еще чего и рторрент начинает усердно кушать проц. Это применимо, если рторрент запущен с одинаковыми параметрами нескольно раз, т.е используется один и тот же конфиг при запуске. Косвенно, хоть и маловероятно, возможно настройки мин\макс кол-ва пиров\сидов и тп настройки влияют на некорректную работу программы, но это предстоит выяснить.
ЗЫ у меня крутится 44 торрента, на данный момент рторрент проработал стабильно 35 часов, винт подцеплен 2'5 WD1600BEAS напрямую в точке доступа, и иногда слышны потрескивания винчестера. Косвенно можно судить что ему не хватает питания - пока не проверял (об этом уже писали на форуме, может решиться покупкой активного usb-концентратора) и также, косвенно, это может являться причиной как раз таки вылета рторрента при его работе с винтом.
ЗЫ да, еще забыл - ресурсоемкие приложения это я так понимаю допустим тягать чего-нибудь по smb на максимуме, процессор и память в такие моменты кушается хорошо, это понятно. Однако рторрент работал прекрасно и раздавалось (тянули с меня) 12 раздач с 14 подключенными пирами одновременно с тем, что я выкачивал фильм с харда на точке доступа.
1 В какой-то момент рторрент если смотреть через top забивает процессор под 95% и никак не откликается ни на какие действия ни через морду ни через консоль
Взять libcurl отсюда - http://wl500g.info/showthread.php?t=14693&highlight=libcurl и больше такое повторяться не будет.
Взять libcurl отсюда - http://wl500g.info/showthread.php?t=14693&highlight=libcurl и больше такое повторяться не будет.
Взял и поменял, только все равно на проверке хэша rtorrent падает, сегодня уже два раза падал, запускал руками.
Взял и поменял, только все равно на проверке хэша rtorrent падает
На проверке хеша - вполне может, это ресурсоемкая операция. Речь в изначальном постинге шла о забитии процессора в произвольный момент. Так вот, в этом виновата последняя сборка libcurl из репозитария. В Вашем же случае можно посоветовать только одно - не "чесать" роутер, когда rtorrent занимается хешированием на файлах большого объема. Ну и, возможно, озаботиться питанием диска.
Novik ок, спасибо, я читал, но не обратил внимания - думал что обновили уже, а про библиотеку просто забыл.
Novik ок, спасибо, я читал, но не обратил внимания - думал что обновили уже
Ее с тех пор уже дважды обновляли. Первый релиз был нормальным, а вот второй и последний - сами видите, какой...
а что, никто из девелоперов эту проблему не замечает что-ли?
ЗЫ установка 1-й версии помогла.
uinoksk спасибо за идею про скрипт, мне пригодился, но в одном месте логика как-то не так для меня работает:
#!/bin/sh
if (expr $(ps -C rtorrent -o %cpu | grep -E '[0-9]') \> 55 > /dev/null 2>&1) then (kill -9 $(ps -C rtorrent -o pid | grep -E '[0-9]');logger 'rtorrent крякнулся +++++++ cpu time limit') fi && sleep 5 && /opt/etc/init.d/S99rtorrent start;
if !(pidof rtorrent > /dev/null 2>&1) then (/opt/etc/init.d/S99rtorrent start;logger 'rtorrent крякнулся +++++++++++++++ down')fi;
Посмотрите конец первой строки - после fi идет &&. Не значет ето, что сначала будет проверка if а остальное за fi исполнится не зависимо от результата проверки? Например:
if (expr $(ps -C rtorrent -o %cpu | grep -E '[0-9]') \> 55 > /dev/null 2>&1) then (kill -9 $(ps -C rtorrent -o pid | grep -E '[0-9]');logger 'rtorrent крякнулся +++++++ cpu time limit') fi && sleep 5 && echo 'will this run?';
запустил скрипт и он мне вывел 'will this run?' через 5 сек. Выходит - /opt/etc/init.d/S99rtorrent start будет выполнятся не зависимо от того, перевалил-ли rtorrent за 55 или нет, и в конце получится куча работающих rtorrent ?
Может вот так лучше:
if (expr $(ps -C rtorrent -o %cpu | grep -E '[0-9]') \> 55 > /dev/null 2>&1) then (kill -9 $(ps -C rtorrent -o pid | grep -E '[0-9]');logger 'rtorrent крякнулся +++++++ cpu time limit';sleep 5;/opt/etc/init.d/S99rtorrent start) fi;
Извините, если я что-то не так понял, в юниксе еще новичок :D
Еще вопрос - что делать с rtorrent.lock файлом - надо его стереть перед запуском упавшего rtorrent или оставить?
Лично у меня проблема решилась установкой свопа
Я поставил своп 256Мб, видно, что он не полностью используется, но rtorrent падает все равно (такого, что жрет много CPU, не видел пока; просто процесс почему-то вырубается).
да что-то до сих пор libcurl нерабочаяя в репозитории :( интерфейс тормозит, загрузка проца 98% ничего не качает сответственно и ничего не раздает rtorrent.
со старой 4.0.1 работает вроде нормально