Еще одна проблема выявилась при загрузки русских файлов.
Набираю /opt/etc/init.d/S99wget stop
Пишет Shutting down check.wget.tcl... done.
Но загрузка продолжается.
Набираю заново
Пишет Shutting down check.wget.tcl... not startted.
Вот.
Я уж успел и свежую асусовскую прошивку поставить - тоже глючит, русские закачки сами собой пропадают.
Last edited by igaryan; 28-06-2007 at 17:28.
Ссылка недоступна. Попробую сам поэксперементировать, но ничего не гарантирую. Русские буквы в ссылках - это зло.
RT-N56U / Padavan FW
Что-то у меня все-таки глючит этот скрипт и с английскими файлами. Вариант от Megarem вообще закачивает только первый файл. Оригинал от al37919 работает, но криво: первые два файла по несколько килобайт закачалось нормально, потом пошел многотомный архив, файлы по 95 Мб, первый файл - закачалось 165 Мб, второй 116 Мб, в папке partial почему-то 2 файла. Вообщем глюки. А есть на форуме еще подобные скрипты?
полагаю, что дело в конкретных ссылках. За загрузку отвечает wget --- один из наиболее зрелых и популярных загрузчиков. Возможно, он не со всеми новомодными веб-мастерскими извратами умеет справляться, тем более, что эта братва любит бороться с неинтерактивными способами закачки --- нет заработка на показе рекламы.
в partial может быть легко хоть десять файлов:
1) если url добавлен в начало списка и wget прибит. Это задумывалось специально, как возможность приоретизации закачек (можно даже сделать автоперезапуск при изменении первой строки в списке). При этом закачанная часть предыдущей закачки не пропадает, а ждет пока до нее дойдет очередь и докачивается.
2) если имя файла изменилось в процессе закачки --- url то у Вас не прямой.
В общем, ИМХО, ищите глюки в Ваших УРЛах.
P.S. Если wget не по душе, на роутере еще доступен curl
Пока сделал проще - вручную запустил wget на закачку каталога. В принципе достаточно команд wgetа, чтоб управлять закачками. Как-то сразу я не понял этого :-)
вот это уже дело
wget, кстати, и список url-ов из файла читать может. Только добавлять их туда нельзя без перезапуска
Привет Всем.
Народ, кто подскажет такую вещь.
Установил указанные скрипты, запустил - все работает. Но есть одно очень важное НО...
Обратил внимание, что очень медленно качает... (относительно ширины канала) а так же что команда "vi" сжирает все процессорное время.
Как я понимаю в это м и проблема медленной закачки. Можно ли как-нибудь сделать не столь интенсивный анализ лога?
А что такое, пардон, комманда "vi" ?команда "vi" сжирает все процессорное время
Анализ лога тут ни при чем. Из лога раз в 30 секунд проверяются только три последних строчки, чтобы узнать закончилась ли очередная закачка и решить почему.
Можно запустить для проверки загрузку с помощью wget напрямую.
Это проблема не скрипта. Причины могут быть разные, например нестабильное соединение или медленный сервер, с которого идет закачка. Возможное решение этой проблемы - скачка файла в несколько потоков (ну или одновременная закачка нескольких файлов). У меня была точно такая же проблема. Скорость прыгала в диапазоне 9-12 кил при скачке. После перехода на axel и 3 потока канал стал забиваться полностью и прыжки скорости исчезли.
Вообщем подожди немного, я планирую выложить свою полностью переписанную версию скрипта, которая будет работать и с вгетом и с акселем. Сам скрипт в принципе уже отлажен, надо только немного дописать веб-морду к нему.
RT-N56U / Padavan FW
Я согодня проведу тесты.
Но на состояние на вчерашний вечер ситуация была такова:
Если анализируемый лог-файл находится на юсб-венике, скорость около 150кБАЙТ в сек.
а если на родной флешке (/tmp/wget.log) - что обеспечивает более быстрое чтение а соответсвенно и анализ лога, то 250 - 300КБАЙТ в сек.
И все процесорное время в обоих случаях пожирает "vi".
Канал большой, можно качать почти 3Мбайта в сек. при чем проверено несколько раз между роутером и сервером. Канал тут не причем, с сервер тоже - это 100%.
Еще раз повторю, что проблема не может быть в анализе лога, т.к. анализ заключается в том, что раз в 30 сек проверяются последние три строки лог-файла.
Однако, возможно проблема в записи лога wget-ом. Он пишет один символ на каждый килобайт информации, причем скорее всего не пакетом, а по отдельным байтам. Т.е. число обращений к файлу лога в процессе записи может быть значительным. Хотя все равно странновато, что он может так тормозить.
/tmp/wget.log находится не на встроенной флешке, а в оперативной памяти, т.е. запись туда производится действительно быстрее.
vi --- это текстовой редактор. Он не используется данным скриптом и пожирать ничего не может. Чем меряли это "пожирание процессорного времени"?
ну и как с новой версией скрипта ???