Stormcrawler медленный с большой задержкой сканирования 300 доменов

В настоящее время я борюсь с этой проблемой примерно 3 месяца. Сканер загружает страницы каждые 10 минут, но ничего не делает между ними. С очень низкой общей пропускной способностью. Параллельно просматриваю 300 доменов. Что должно составлять около 30 страниц в секунду с задержкой сканирования 10 секунд. В настоящее время это около 2 страниц в секунду.

Топология работает на ПК с

  • 8 ГБ памяти
  • Обычный жесткий диск
  • Core Duo CPU
  • Ubuntu 16.04

Elasticsearch установлен на другом компьютере с такими же характеристиками.

Здесь вы можете увидеть показатели из панели управления Grafana.

Панель управления Grafana

Они также отражаются в задержке процесса, наблюдаемой в пользовательском интерфейсе Storm:

Storm UI

Моя текущая архитектура Stormcrawler:

spouts:
  - id: "spout"
    className: "com.digitalpebble.stormcrawler.elasticsearch.persistence.AggregationSpout"
    parallelism: 25

bolts:
  - id: "partitioner"
    className: "com.digitalpebble.stormcrawler.bolt.URLPartitionerBolt"
    parallelism: 1
  - id: "fetcher"
    className: "com.digitalpebble.stormcrawler.bolt.FetcherBolt"
    parallelism: 6
  - id: "sitemap"
    className: "com.digitalpebble.stormcrawler.bolt.SiteMapParserBolt"
    parallelism: 1
  - id: "parse"
    className: "com.digitalpebble.stormcrawler.bolt.JSoupParserBolt"
    parallelism: 1
  - id: "index"
    className: "de.hpi.bpStormcrawler.BPIndexerBolt"
    parallelism: 1
  - id: "status"
    className: "com.digitalpebble.stormcrawler.elasticsearch.persistence.StatusUpdaterBolt"
    parallelism: 4
  - id: "status_metrics"
    className: "com.digitalpebble.stormcrawler.elasticsearch.metrics.StatusMetricsBolt"
    parallelism: 1

с конфигурацией (здесь самая актуальная часть):

config:
  topology.workers: 1
  topology.message.timeout.secs: 300
  topology.max.spout.pending: 100
  topology.debug: false

  fetcher.threads.number: 50

  worker.heap.memory.mb: 2049
  partition.url.mode: byDomain

  fetcher.server.delay: 10.0

и вот конфигурация шторма (тоже только соответствующая часть):

nimbus.childopts: "-Xmx1024m -Djava.net.preferIPv4Stack=true"

ui.childopts: "-Xmx768m -Djava.net.preferIPv4Stack=true"

supervisor.childopts: "-Djava.net.preferIPv4Stack=true"

worker.childopts: "-Xmx1500m -Djava.net.preferIPv4Stack=true"

Вы хоть представляете, в чем может быть проблема? Или проблема только в железе?

Что я уже пробовал

  • Увеличьте fetcher.server.delay до более высокого и более низкого значения, которое ничего не меняет
  • Уменьшайте и увеличивайте количество потоков извлечения
  • Поигрался с параллелизмом
  • Вычисляется, если это пропускная способность сети. При пропускной способности 400 Мбит / с и среднем размере страницы 0,5 МБ это будет 15 МБ / с, что будет 120 Мбит / с, что также не должно быть проблемой.
  • Увеличено количество рабочих

У вас есть еще идеи, которые я должен проверить, или причины, которые могли бы объяснить медленную загрузку? Может, дело и в медленном железе? Или узким местом является Elasticsearch?

заранее большое спасибо

РЕДАКТИРОВАТЬ:

Я изменил топологию на двух рабочих и повторяю ошибку

2018-07-03 17:18:46.326 c.d.s.e.p.AggregationSpout Thread-33-spout-executor[26 26] [INFO] [spout #12]  Populating buffer with nextFetchDate <= 2018-06-21T17:52:42+02:00
2018-07-03 17:18:46.327 c.d.s.e.p.AggregationSpout I/O dispatcher 26 [ERROR] Exception with ES query
java.io.IOException: Unable to parse response body for Response{requestLine=POST /status/status/_search?typed_keys=true&ignore_unavailable=false&expand_wildcards=open&allow_no_indices=true&preference=_shards%3A12&search_type=query_then_fetch&batched_reduce_size=512 HTTP/1.1, host=http://ts5565.byod.hpi.de:9200, response=HTTP/1.1 200 OK}
	at org.elasticsearch.client.RestHighLevelClient$1.onSuccess(RestHighLevelClient.java:548) [stormjar.jar:?]
	at org.elasticsearch.client.RestClient$FailureTrackingResponseListener.onSuccess(RestClient.java:600) [stormjar.jar:?]
	at org.elasticsearch.client.RestClient$1.completed(RestClient.java:355) [stormjar.jar:?]
	at org.elasticsearch.client.RestClient$1.completed(RestClient.java:346) [stormjar.jar:?]
	at org.apache.http.concurrent.BasicFuture.completed(BasicFuture.java:119) [stormjar.jar:?]
	at org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.responseCompleted(DefaultClientExchangeHandlerImpl.java:177) [stormjar.jar:?]
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.processResponse(HttpAsyncRequestExecutor.java:436) [stormjar.jar:?]
	at org.apache.http.nio.protocol.HttpAsyncRequestExecutor.inputReady(HttpAsyncRequestExecutor.java:326) [stormjar.jar:?]
	at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:265) [stormjar.jar:?]
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:81) [stormjar.jar:?]
	at org.apache.http.impl.nio.client.InternalIODispatch.onInputReady(InternalIODispatch.java:39) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:114) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104) [stormjar.jar:?]
	at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588) [stormjar.jar:?]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_171]
Caused by: java.lang.NullPointerException

Тем не менее, процесс сканирования кажется более сбалансированным, но по-прежнему не получает много ссылок.

введите здесь описание изображения

Также после запуска топологии в течение нескольких недель задержка сильно увеличилась.

введите здесь описание изображения


person Jonas Pohlmann    schedule 20.06.2018    source источник


Ответы (2)


Извините за поздний ответ, только что вернулся из отпуска.

Судя по графику, воркер перезапускается, что наводит на мысль, что что-то блокирует или ломает топологию. Через некоторое время, когда ничего не происходит, рабочий перезапускается, он обрабатывает некоторые URL-адреса, и проблема возникает снова.

Вы проверяли журналы на наличие сообщений об ошибках? В логах есть дамп памяти? Можете ли вы выделить URL-адреса, которые вызывают проблему?

person Julien Nioche    schedule 02.07.2018
comment
Я думаю, что это не зависит от URL-адреса, а является проблемой в целом, поскольку это всегда было одним и тем же случаем для нескольких разных URL-адресов. Я обновил текущий статус, который не работает более плавно с некоторыми изменениями конфигурации, но не извлекает много URL-адресов .. С заданным числом это будет около 2 страниц в секунду, что очень мало .. - person Jonas Pohlmann; 03.07.2018
comment
Он не сможет получить много URL-адресов, если носики не могут получить результаты, о чем свидетельствует ошибка в журналах. Вы можете установить для журналов уровень DEBUG и посмотреть, как выглядят запросы ES, генерируемые носиками, и посмотреть, сможете ли вы воспроизвести проблему, запустив их непосредственно в ES. - person Julien Nioche; 04.07.2018

Это происходит, когда вы не ack() или fail() все кортежи во всех ваших (пользовательских) болтах. Кроме того, при передаче из промежуточного болта убедитесь, что новый кортеж правильно привязан к предыдущему кортежу. См. этот ответ SO для объяснения.

У меня была такая же проблема, также с настройкой ES. Сначала я подумал, что это касается nextFetchDate логики носика ES, но после отключения моих пользовательских болтов проблема была исправлена. Итак, я обнаружил, что где-то пропустил ack() кортеж. Это привело к потере неподтвержденных кортежей в топологии, которые затем будут повторно отправлены через 10 минут / 600 секунд.

Хотя я не нашел, где определяется 10-минутный тайм-аут повтора, поскольку механизм повтора шторма был установлен на 5 минут через topology.message.timeout.secs: 300

person nrnrn    schedule 04.07.2018