В настоящее время я борюсь с этой проблемой примерно 3 месяца. Сканер загружает страницы каждые 10 минут, но ничего не делает между ними. С очень низкой общей пропускной способностью. Параллельно просматриваю 300 доменов. Что должно составлять около 30 страниц в секунду с задержкой сканирования 10 секунд. В настоящее время это около 2 страниц в секунду.
Топология работает на ПК с
- 8 ГБ памяти
- Обычный жесткий диск
- Core Duo CPU
- Ubuntu 16.04
Elasticsearch установлен на другом компьютере с такими же характеристиками.
Здесь вы можете увидеть показатели из панели управления Grafana.
Они также отражаются в задержке процесса, наблюдаемой в пользовательском интерфейсе Storm:
Моя текущая архитектура 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
Тем не менее, процесс сканирования кажется более сбалансированным, но по-прежнему не получает много ссылок.
Также после запуска топологии в течение нескольких недель задержка сильно увеличилась.