yads
написал 10 апреля 2009 года в 15:39 (959 просмотров)
Ведет себя
неопределенно; открыл 6 тем в форуме, оставил 36 комментариев на сайте.
Несколько роботов с разных сайтов параллельно качают страницы. Достичь 100% загрузки увеличивая количество роботов не удается — примерно на 60% загрузка перестает увеличиваться. В чем проблема? Как устранить? (при скачивании 1 большого файла загрузка канала близка к 100%)
Последние комментарии
- OlegL, 17 декабря в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Может быть, это ограничения самих сайтов, с которых осуществляется скачивание? Не пробовали с других?
Ограничение на количество TCP-сессий провайдером?
Если бы это было ограничение самих сайтов, то увеличение количества роботов увеличивало бы загрузку канала (каждый робот качает с одного сайта, другой с другого).
Из ответа провайдера:
Тупо не хватает процессорного времени роботам.
Загрузка процессора 60%.
Других ресурсов: максимальное количество открытых файлов, роботы пишут на диск и ждут его. Ищи узкое место!
Узкое место я ищу последние полгода, пока безуспешно. С диском роботы работают через mysql (надеюсь он бы завопил если бы файлов не хватило). Объем данных записываемых на диск не превышает 2% от того что можно успеть записать. Но процессор в состоянии ожидания ввода-вывода 20-40% времени.
Возможность создать базу на tmpfs есть?
Модифицировать робота, чтобы он в к ней вообще не обращался? (для тестирования конечно)
tmpfs это ramdisk? оперативки точно не хватит даже для тестирования.
Попытка оторвать роботов от данных получилась неуспешной — им надо не только писать но и немножко читать.
Удалось только разнести таблицы по двум винчестерам. Ожидание ввода вывода процессором упало вдвое, но idle не выросло.
Загрузка канала не выросла.
А не является ли процесс открытия соединения чем-то особенным? Может ли одновременно идти более одного процесса открытия соединения? (почему-то суммарное время (по всем роботам) открытия соединений за N секунд не превышает N).
Установление соединения — это такая же отсылка пакетов, как и любых других. Вот над этим стоит подумать http://fasterdata.es.net/TCP-tuning/linux.html особенно над размером очереди интерфейса.
Все что сказано увеличил — все равно тоже ограничение.
Еще один тест и еще более непонятный результат. Каждый робот стал открывать не по одному, а по два соединения (по второму соединению запрос на данные не отправляется, оно просто открывается вместе(последовательно) с первым и закрывается вместе с первым). Среднее время открытия ОДНОГО соединения увеличилось в два раза. Загрузка канала немного уменьшилась.
Явно проблемы кроются в сети. Как насчет локального сетевого оборудования. Мне встречался роутер, не переносивший большой нагрузки маленькими пакетами.
Я пробовал подключаться напрямую (без роутера) — скорость упала в полтора раза.
Скорее всего из-за затухания сигнала, интересно попробывать с другим роутером.
Новый роутер покупать планируется, но не в ближайшее время.