Доброго времени суток.

Я использую apache http async http://hc.apache.org/httpcomponents-asyncclient-dev/index.html для сбора данных. Нагрузка пока небольшая - 4-5 страниц в секунду. Но эта нагрузка только для тестирования.

Проблема в том, что где-то на 7000+ странице, начинаются затупы по 20 секунд в минуту, при резолве внешнего соединения и заодно при создании соединения клиента. То есть примерно каждую минуту он тупит 20 секунд. Похоже на то, что linux (fedora) пытается отправить несколько SYN запросов, как раз укладываясь в 20 секунд, но не получает ответа.

Я мог бы подумать, что проблема в превышении лимита открытых соединений, но количество соединений, которые можно увидеть - ~140-190. Лимит - 32 тыс.

Такое ощущение, что что-то клиент всё-таки не закрывает и от этого проблемы... Попытался проблему решить пересозданием клиента, а заодно вызовом shutdown, так как он все коннекты закрывает и отменяет, но эффекта это не дало.

Keepalive - использовался дефолтный апачевский, который в случае чего возвращает -1 либо значение из заголовка, пробовал и без keepalive.

Есть одна странная мысль - я запускаю эту штуку из дома и провайдер такой SYN трафик может блокировать. Больше идей у меня нет.

Может уважаемые коллеги подскажут куда можно покопать?

Отвечу сам себе :)

Кажется починил, с помощью замены клиента на - https://github.com/AsyncHttpClient/async-http-client .
Какой-то странный сетевой затуп по-прежнему есть время от времени, но судя по логам и статистике, он уменьшился. Кроме того эта библиотека с забором данных работает лучше. Затуп сокета почти не мешает другим закачкам, поэтому очередь загрузок непрерывна. Тфу-тфу-тфу. Оставил пока на ночь.

p.s. кстати да, затуп сокета не связан с хостом, он происходил за время тестов на каждом из тестовых хостов.

Тест показал, что от смены клиента проблема не исчезает. Так что актуально.

Но похоже, что проблема уже не на стороне java, а всё-таки либо системная, либо сетевая. Может кто-нибудь сталкивался?

Спасибо.

Leonidv,

Привет и спасибо :)

Без ограничения времени - никуда, тут другой вопрос - что надо выбрать правильный timeout, чтобы хорошие, но медленные урлы не обрубить. 20 секунд - время большое, конечно, но если хочется загружать еще и медиаконтент, то маловато и этого. Кстати apache http client и ning предлагают соответствующие настройки, так что с этим проблем нет.

Проблему, надеюсь, окончательно поборол - установкой локального днс сервера/resolver'a - bind . + увеличил время кеша network.address для профилактики. Сейчас, тфу-тфу-тфу, всё работает быстро, только лишь реально медленные ссылки уходят в таймаут.

Leonidv,

С настройками SoTimeout, ConnectionTimeout зависало? А какая версия?

У меня сейчас синхронный апачевский клиент используется только для проверки состояния скачиваемых сайтов, опрашивается раз в 20 секунд, пока не вис, тфу-тфу-тфу, а вот TimeoutException'ы вываливает частенько. Верчии использовал начиная с 4. Но посмотрим, у меня до текущей реализации тоже был future против зависаний. Заодно после закачки была куча логики, которая тоже зависела от IO, поэтому future был очень уместен.

История имеет продолжение :)

Если вам требуется очень быстрый асинхронный сбор данных с множества источников, то не рекомендую использовать ни apache http client, ни ning async client. Последний, к слову, вроде как штатно используется в фреймворке play, я нашёл темы в гугл группах play по багам клиента.

Несмотря на то, что ning по умолчанию использует netty, сделан он недостаточно эффективно. Apache async http client - тоже. Счастья с этими продуктами я так и не испытал и пришлось написать свой клиент поверх netty. Благо в интернете есть примеры .

Проблемы возникают если поток данных достаточно большой и сайты для сбора неоднородны и могут выдавать непредсказуемые результаты. В итоге получается выбор - либо танцевать с бубном вокруг клиентов и править их код, либо написать сразу по-человечески на базе nio, netty.

LeonidvЯ с асинхронными не работал, т.к. не увидел их явной выгоде, а сделать надо было быстро. Использовал только httpclient.
SoTimeout - не помню, ставил или нет, но ConnectionTimeout точно мне не подходил. Там было видно в потоках, что процесс создавал и устанавливал связь и похоже, получал какие-то ответы от сервера (потому что не срабатывал ReadTimeout).

Я тогда прогуглил ситуацию и нашел на stackoverflow совет/правило все такие вызовы оформлять через feature. Добавил - сборка стабилизировалась.

А очень быстрый - это у вас сколько?

Нужно кравлить несколько сотен доменов одновременно. Сначала мой кравлер был на потоках и обрабатывал штук 50 доменов, по потоку на домен, но сейчас требования изменились. Асинхрон позволяет гораздо лучше контролировать задачи, сеть и использует меньше ресурсов.

Сейчас у меня асинхронный resolve, а после него идёт уже отправка запроса + ограничение на количество запросов, это позволяет нагружать сеть равномерно. Также я закачиваю заголовки и если они мне не нравятся - закачку обрубаю, это экономит сеть и ресурсы. С netty проверка только одних заголовков и разные действия после этого - очень удобно делается - в HttpHandler.

Хотя в целом это ужасный геморрой и новые, сложновыловимые баги.

Leonidv,

В Nutch используется Hadoop. В частности, насколько я знаю, в тасках хадупа происходит закачка ссылок.

1) для меня map-reduce job'ы - это всё-таки задачи, с очевидным результатом. Например обработка данных в хадупе - отличная мысль. Для того он и сделан. Но вот IO в хадупе, да еще и с непредсказуемым результатом - это очень опасная штука. Например многие адреса порождают довольно много редиректов, кроме того есть затупы resolve, сайты часто падают сами по себе на минуту-час-день. Уверен, что в Nutch как-то решили эти проблемы, но посмотрев документацию я понял, что конфигурить это всё - сложно. Проще написать своё. Впрочем я - заядлый велосипедостроитель :)

2) мой кравлер кормит ссылками сам себя постоянно. Разумеется, есть база ссылок и есть хранилище, в котором хранятся recrawlDate и прочее по каждой ссылке. Но он может просто запуститься и работать, работать, работать, пока я не остановлю его. А хадуп джоба, которая работает 2 недели - это какой-то ахтунг. При этом кравлеру особой масштабируемости не надо, так как мы всё-равно упрёмся в сеть. Если только сеть не 10 гигабит :)

И всё-таки список урлов на фетчинг - это хорошая штука, если у нас урлов миллиарды. И доменов миллионы. Иначе мы просто не сможем контролировать это всё. Но это не мой случай, у меня просто несколько списков урлов по 50 штук. Всего - несколько сотен на текущий момент.

3) Это решение - относительно простое.

4) Это часть инфраструктуры, хотя можно было бы эту инфраструктуру реализовать на хадупе, но смысла в этом не было. Хадуп всё-таки требователен, да и настраивается непросто. В общем исторически так сложилось.

АлексейС....Но это не мой случай, у меня просто несколько списков урлов по 50 штук. Всего - несколько сотен на текущий момент. ....

Под урлами я имею в виду домены, конечно.