Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 66
А скрипт когда качает у вас пинг на яндекс не возрастает?
Да и вообще вам нормальный шейпер нужен просто :)
Возрастает. Именно поэтому я wget убиваю и чуть-чуть жду :)
(killall wget — это как раз оно)
Шейпер? А шо це такое?
(killall wget — это как раз оно)
Шейпер? А шо це такое?
Эээээ…
Шейпинг — ограничение пропускной способности канала для отдельного узла сети ниже технических возможностей канала до узла. Шейпинг обычно используется как средство ограничения максимального потребления трафика со стороны узла сети.
Устройство (или программу), осуществляющую ограничение скорости называют шейпер.
Нуууу, это не то. Я же тоже хочу работать с нормальной скоростью :)
Нужно только wget ограничивать, а не весь трафик с моего компьютера.
Нужно только wget ограничивать, а не весь трафик с моего компьютера.
То, то. Шейперы разные бывают :)
Я для похожих целей использую delay_pools в squid
Я для похожих целей использую delay_pools в squid
Вот, как раз, squid'овские delay_pools — не то (на сколько я знаю). Они же не могут ограничить работу одной только утилиты, только целый хост. А файлы я качаю с того же компьютера, на котором работаю.
Плюс, suqid штука достаточно большая, и поднимать ее на своем рабочем компьютере только для такой мелкой задачи — слегка непропорционально.
Плюс, suqid штука достаточно большая, и поднимать ее на своем рабочем компьютере только для такой мелкой задачи — слегка непропорционально.
Все равно шейперы бывают разные :)
сквид хоть и мощная, но небольшая штука.
так можно по разному коннектится к сквиду.
например все программы подефолту под одним лоином, wget под другим. вот и получаетм 2 асл которые рулим как нам надо.
так можно по разному коннектится к сквиду.
например все программы подефолту под одним лоином, wget под другим. вот и получаетм 2 асл которые рулим как нам надо.
Вся суть этого скрипта, что он отдает канал на закачку файла, только когда канал не используется. И только на закачку (не ограничивая компьютер целиком). Squid так может? (я просто не в курсе)
Squid, возможно и не может, а вот если порыться в QoS то наверняка там есть приоритизация траффика по его типу. Т. е. грубо говоря, *.mp3 файл качается на всю (или не на всю, тут как шейпер настроишь), но только до тех пор, пока не пойдет загрузка *.htm.
Посколько TCP/IP стек формирует очереди, то, грубо говоря, веб-странички идут «вне очереди», а уже после этого дается возможность скачатся mp3шке. Скорость не теряется никогда, веб летает. Конечно, возникнут сложности с настройкой, если ваши коллеги тоже не прочь покачать те же самые типы файлов :)
QoS+шейпер это то, что вам нужно. Но(!) если повозится с настройками.
Посколько TCP/IP стек формирует очереди, то, грубо говоря, веб-странички идут «вне очереди», а уже после этого дается возможность скачатся mp3шке. Скорость не теряется никогда, веб летает. Конечно, возникнут сложности с настройкой, если ваши коллеги тоже не прочь покачать те же самые типы файлов :)
QoS+шейпер это то, что вам нужно. Но(!) если повозится с настройками.
Да и не обязательно весь траффик пускать через сквид. Пускай через него работает только wget. В скрипт надо будет добавить
А вообще, есть такая штучка для линухов, называется
export http_proxy="http://127.0.1.2:8080" и export ftp_proxy="http://127.0.1.2:8080", а к вызову wget'a если есть авторизация прокси надо добавить --proxy-user=… и --proxy-password=…А вообще, есть такая штучка для линухов, называется
trickle — позволяет управлять шириной канала для отдельных процессов. Попробуйте, может это то, что надо.там выше ошибочное высказывание что delay_pools рулят только хостами и сетями.
На самом деле они оперируют понятием acl которое может включать в себя например аутентификацию на прокси. Для вашей задачи достаточно 2- пулов 1-го и 2-го классов. В общем, RTFM — сквид очень гибкая штука.
На самом деле они оперируют понятием acl которое может включать в себя например аутентификацию на прокси. Для вашей задачи достаточно 2- пулов 1-го и 2-го классов. В общем, RTFM — сквид очень гибкая штука.
Лучше уж не просто шейпить, а на базе QoS. В общих чертах это описано в статье про QoS (в Википедии)
Если я не ошибаюсь, то регулировать QoS, или нет — задача рутера. У меня до рутера доступа нет. Да и не пропорционально, опять же, в рутер лезть для таких целей.
Плюс, мне нужно понижать приоритет конкретных пакетов, а не повышать приоритет всех остальных.
Плюс, мне нужно понижать приоритет конкретных пакетов, а не повышать приоритет всех остальных.
Немного ошибаетесь :) QoS есть в любой современной операционной системе. В винде, конечно, нужны надстройки, хотя и там на базовом уровне всё есть. Но вам будет мало того, что есть. Можете попробовать Traffic inspector, там это есть в более грамотном состоянии, чем в голой винде (хотя и не слишком много возможностей). Ну а если вы под линуксом или фряхой, то наверняка всё знаете и так :)
if [ `jobs %wget | mawk '{if (NR==1) print $2}'`0 == Running0 ]
then
# Если еще не докачал, то прерываем его работу вручную.
killall wget
else
# Ну, а если докачал, то выходим из while'а, и большими шагами идем к выходу.
break
fi
then
# Если еще не докачал, то прерываем его работу вручную.
killall wget
else
# Ну, а если докачал, то выходим из while'а, и большими шагами идем к выходу.
break
fi
какой-то странный хабр последнее время — в процессе набивания комментария, берёт и постит его раньше времени :(
|
v
и «странные нолики» не нужны (если обернуть `` в кавычки)
if [ `jobs %wget | mawk '{if (NR==1) print $2}'`0 == Running0 ]|
v
$status=$(jobs %wget | mawk '{if (NR==1) print $2}')
if [ "$status" == "Running" ]и «странные нолики» не нужны (если обернуть `` в кавычки)
предложение по улучшению:
1) запуск wget
2) sleep
3) проверка — не скачал ли уже всё? (если скачал — выход)
4) пинг
5a) если пинг хороший, и в предыдущем цикле был тоже хороший, то вгет не трогаем
5b) если пинг хороший, и в предыдущем цикле был плохой, то вгет перезапускаем с повышенным приоритетом
5c) если пинг плохой, а был хороший, то даем юзерам поработать
5d) если пинг плохой, и был плохой, то либо вгет не трогаем, либо останавливаем вообще на некий период
ключевые отличия — пинг запускается синхронно с вгетом, если ситуация в сети не меняется, то лишних kill'ов вгета нет => оптимальнее использование времени.
а за счет того что во время пинга вгет еще качает — накидываем на оценку задержки например лишние 100мс если «быстрый» режим, и ничего не накидывать если «медленный».
1) запуск wget
2) sleep
3) проверка — не скачал ли уже всё? (если скачал — выход)
4) пинг
5a) если пинг хороший, и в предыдущем цикле был тоже хороший, то вгет не трогаем
5b) если пинг хороший, и в предыдущем цикле был плохой, то вгет перезапускаем с повышенным приоритетом
5c) если пинг плохой, а был хороший, то даем юзерам поработать
5d) если пинг плохой, и был плохой, то либо вгет не трогаем, либо останавливаем вообще на некий период
ключевые отличия — пинг запускается синхронно с вгетом, если ситуация в сети не меняется, то лишних kill'ов вгета нет => оптимальнее использование времени.
а за счет того что во время пинга вгет еще качает — накидываем на оценку задержки например лишние 100мс если «быстрый» режим, и ничего не накидывать если «медленный».
Если пинг запускается синхронно с wget'ом (без прекращения закачки), то время пинга будет очень большое, т. к. wget жрет весь канал и неохотно его отдает.
Что можно сделать, так это, если в прошлом цикле был хороший пинг, и в этом тоже, то можно длинну цикла увеличить. И, соответственно, если 2 раза подряд плохой пинг, то дать юзерам подольше нормально поработать.
Что можно сделать, так это, если в прошлом цикле был хороший пинг, и в этом тоже, то можно длинну цикла увеличить. И, соответственно, если 2 раза подряд плохой пинг, то дать юзерам подольше нормально поработать.
а вы вгету в быстром режиме тоже скорость зарежьте на 90% от максимальной. чтобы для пингов кусочек полосы остался.
Все равно не получится различить, медленный пинг из-за того, что wget все занимает, или из-за того, что юзеры полезли. Юзеров нужно любить, и быть увереным, что им эта закачка не мешает :)
Да, есть еще догадка, что wget, заряженный на 90% проиграет по производительности wget'у, заряженному на 100%, но прирываемому раз в 20 секунд. Хотя, в этом я не уверен — считать надо.
с точностью до наоборот. на установку-переустановку соединения больше времени и ресурсов тратится.
Я как посчитаю — скажу :)
Сейчас работать надо.
Сейчас работать надо.
И правда. Вот статистика, ниже немного рассчетов:
Средняя пауза — 4.2 секунды
Средняя закачка — 19.3 секунды
Срещний цикл — 23.5 секунд
За цикл 90% скрипт закачает примерно 23.5*download_speed*0.9 байт.
За тот же цикл текущий скрипт закачает 19.3*download_speed байт.
Итого, постоянно качающий скрипт закачает примерно на 20% больше, чем непостоянно качающий.
Средняя пауза — 4.2 секунды
Средняя закачка — 19.3 секунды
Срещний цикл — 23.5 секунд
За цикл 90% скрипт закачает примерно 23.5*download_speed*0.9 байт.
За тот же цикл текущий скрипт закачает 19.3*download_speed байт.
Итого, постоянно качающий скрипт закачает примерно на 20% больше, чем непостоянно качающий.
Очень просто. Если поставить limit-rate, который не будет сильно тормозить интернет днем, когда люди работают, то он и ночью, когда никто не работает, тоже канал на полную использовать не будет. А так канал используется на полную всегда, когда он свободен (и даже днем, когда его не используют).
-a
100b/s, это когда инет пользуют сотрудники, чтобы им не мешало. В остальное время wget занимает канал полностью.
У wget'а есть опция -c, которая продолжает закачку (докачивает) файла. Понятно, что если сервер докачку не поддерживает, то ничего не сработает.
У wget'а есть опция -c, которая продолжает закачку (докачивает) файла. Понятно, что если сервер докачку не поддерживает, то ничего не сработает.
Это на весь офис канал 30 кб/сек? новосибирский коммерческий блин интернет (
таким инетом только яндекс пинговать, не более того
канал урезан строго на 2 телефонных потка без запапса, а вы умудряетесь лить по нему музло.
канал урезан строго на 2 телефонных потка без запапса, а вы умудряетесь лить по нему музло.
Я бы сюда ещё добавил очередь закачки, т. е. скрипт читает url'ы из файла или из fifo, чтобы уж нагрузить так нагрузить. Да и жёстко прописывать url в скрипт не очень красиво, хотя бы сделать это через аргумент командной строки или на худой конец через константу.
1. Калибровка: wget без limit-rate иногда, смотрим скорость за 10 секунд
2. Ставим limit-rate на 10% меньше, чем получившаяся скорость и постоянно следим.
3. Если скорость на очередном этапе меньше установленного limit-rate — пора ещё на 10% уменьшить.
4. Если уже несколько минут ровно limit-rate — можно попробовать запустить калибрационное измерение (п.1)
Слежение за скоростью — по размеру файла или по логу wget.
2. Ставим limit-rate на 10% меньше, чем получившаяся скорость и постоянно следим.
3. Если скорость на очередном этапе меньше установленного limit-rate — пора ещё на 10% уменьшить.
4. Если уже несколько минут ровно limit-rate — можно попробовать запустить калибрационное измерение (п.1)
Слежение за скоростью — по размеру файла или по логу wget.
Проверьте свой роутер на доступность по SNMP. Часто бывает, что открыт и без пароля. Снимать текущую скорость по SNMP — это гораздо лучше, чем ping :)
У меня роутер под линуксом без каких-то специальных на то настроек вполне себе поровну траффик распределяет. То есть у меня висит wget в бэкрграунде и я, или кто-то с другого компьютера идёт в инет, то у меня скорость сама по себе на wget падает и всё.
А если торренты, то там уже не поковырявшись с шейпером никак их не подвинуть, но руки не добираются до настройки :)
А если торренты, то там уже не поковырявшись с шейпером никак их не подвинуть, но руки не добираются до настройки :)
Вроде в винде есть служба фоновой загрузки (BITS), которая работает, когда канал свободен. Правда, что плохо, этой службой любят пользоваться вирусы, поэтому она у меня отключена)) Но я думаю, ее можно как-то использовать для этих целей.
-b
wget работает в бекграунде
wget работает в бекграунде
wget bla-bla&
тоже посылает его в бэкграунд. Только это не тот бэкграунд, который хочется получить.
тоже посылает его в бэкграунд. Только это не тот бэкграунд, который хочется получить.
я просто к тому что вы используете & когда вгет имеет для этого опцию, хотя разницы конечно никакой
Просто стандартные штучки bash'а как-то привычнее :)
Откройте консоль в графике, сделайте wget с -b и wget с &. Закройте консоль.
Только в первом случае wget будет жить, второй умрет как дочерний процесс консоли.
Только в первом случае wget будет жить, второй умрет как дочерний процесс консоли.
> хотя разницы конечно никакой
Может вы имели в виду конкретный случай (т. е. то, что здесь это роли не сыграет), тогда я не к месту сказал.
Может вы имели в виду конкретный случай (т. е. то, что здесь это роли не сыграет), тогда я не к месту сказал.
Я, таки, возражаю.
Если сделать wget bla-bla&
и закрыть консоль, то wget остается жить. Его можно найти в ps (ps aux | grep wget)
Если сделать wget bla-bla&
и закрыть консоль, то wget остается жить. Его можно найти в ps (ps aux | grep wget)
если из консоли выйти по-человечески через exit, то во втором случае процесс останется жить
фаерволы позволяют шейпить трафик по пользователям если сорс пакета сама машина с фаерволом, запускаем wget от пользователя с N и задаем его очереди самый низкий приоритет
тут например настройка фаерволла
тут например настройка фаерволла
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Качаем файлы в бэкграунде