Тика Parser замедляя StormCrawler

Вопрос задан: 10 месяцев назад Последняя активность: 8 месяцев назад
up 2 down

У меня есть довольно общая задача, имея несколько тысяч веб-сайтов, и того, чтобы разобрать, как много, насколько это возможно (в адекватной форме, конечно).

Во-первых, я сделал stormcrawlerfight подобные конфигурации, используя JSoup анализатор. Производительность была довольно хорошо, очень стабильно, около 8k выборок в минуте.

Тогда я хотел бы добавить возможность синтаксического анализа PDF/DOC/и т.д.. Поэтому я добавил Тик парсер для разбора HTML без документов. Но я вижу такой метрики: Тика Parser замедляя StormCrawler

Поэтому иногда есть хорошие минуты, иногда падает до сотен в минуту. Когда я удалить Тик поточных записей - все возвращается в нормальное русло. Так что вопрос в целом, как найти причину такого поведения, узкое место. Может быть, мне не хватает какой-то настройки?

Вот то, что я вижу в топологии гусеничного в штормовых UI: Тика Parser замедляя StormCrawler

эс-injector.flux:

name: "injector"

includes:
- resource: true
  file: "/crawler-default.yaml"
  override: false

- resource: false
  file: "crawler-custom-conf.yaml"
  override: true

- resource: false
  file: "es-conf.yaml"
  override: true

spouts:
  - id: "spout"
    className: "com.digitalpebble.stormcrawler.spout.FileSpout"
    parallelism: 1
    constructorArgs:
      - "."
      - "feeds.txt"
      - true

bolts:
  - id: "status"
    className: "com.digitalpebble.stormcrawler.elasticsearch.persistence.StatusUpdaterBol    t"
    parallelism: 1

streams:
  - from: "spout"
    to: "status"
    grouping:
      type: CUSTOM
      customClass:
        className:    "com.digitalpebble.stormcrawler.util.URLStreamGrouping"
        constructorArgs:
          - "byHost"
      streamId: "status"

эс-crawler.flux:

name: "crawler"

includes:
- resource: true
  file: "/crawler-default.yaml"
  override: false

- resource: false
  file: "crawler-custom-conf.yaml"
  override: true

- resource: false
  file: "es-conf.yaml"
  override: true

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

bolts:
  - id: "partitioner"
    className:    "com.digitalpebble.stormcrawler.bolt.URLPartitionerBolt"
    parallelism: 1

  - id: "fetcher"
    className: "com.digitalpebble.stormcrawler.bolt.FetcherBolt"
    parallelism: 1

  - id: "sitemap"
    className: "com.digitalpebble.stormcrawler.bolt.SiteMapParserBolt"
    parallelism: 1

  - id: "parse"
    className: "com.digitalpebble.stormcrawler.bolt.JSoupParserBolt"
    parallelism: 5

  - id: "index"
    className:    "com.digitalpebble.stormcrawler.elasticsearch.bolt.IndexerBolt"
    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

  - id: "redirection_bolt"
    className: "com.digitalpebble.stormcrawler.tika.RedirectionBolt"
    parallelism: 1

  - id: "parser_bolt"
    className: "com.digitalpebble.stormcrawler.tika.ParserBolt"
    parallelism: 1

streams:
  - from: "spout"
    to: "partitioner"
    grouping:
      type: SHUFFLE

  - from: "spout"
    to: "status_metrics"
    grouping:
      type: SHUFFLE     

  - from: "partitioner"
    to: "fetcher"
    grouping:
      type: FIELDS
      args: ["key"]

  - from: "fetcher"
    to: "sitemap"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "sitemap"
    to: "parse"
    grouping:
      type: LOCAL_OR_SHUFFLE

  # This is not needed as long as redirect_bolt is sending html content to index?
  # - from: "parse"
  #   to: "index"
  #   grouping:
  #     type: LOCAL_OR_SHUFFLE

  - from: "fetcher"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "sitemap"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "parse"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "index"
    to: "status"
    grouping:
      type: FIELDS
      args: ["url"]
      streamId: "status"

  - from: "parse"
    to: "redirection_bolt"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "redirection_bolt"
    to: "parser_bolt"
    grouping:
      type: LOCAL_OR_SHUFFLE
      streamId: "tika"

  - from: "redirection_bolt"
    to: "index"
    grouping:
      type: LOCAL_OR_SHUFFLE

  - from: "parser_bolt"
    to: "index"
    grouping:
      type: LOCAL_OR_SHUFFLE

Обновление: Я обнаружил, что я получаю исключит ошибки памяти в workers.log, даже то, что у меня есть множество workers.heap.size 4Гб, рабочий процесс поднимает до 10-15Gb ..

Update2: После того, как я ограничил использование памяти я не вижу OutOfMemory ошибок, но производительность при очень низком уровне. Тика Parser замедляя StormCrawler Тика Parser замедляя StormCrawler

Без Тика - Я вижу 15k получений фидов в минуту. С Тика - все это после того, как высокие бары, сотни за только минуту.

И я вижу это в журнале работников: https://paste.ubuntu.com/p/WKBTBf8HMV/

использование процессора очень высоко, но ничего в журнале.

2 ответа

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

Реклама

up 1 down

Как вы можете видеть в статистике на UI, анализатор болт Тика является узким местом: он имеет емкость 1,6 (значение> 1 означает, что оно не может обрабатывать входные данные достаточно быстро). Это должно улучшить, если вы дадите ему такой же параллелизм в качестве JSOUP анализатор т.е. 4 или более.

up 0 down

Поздний ответ, но может быть полезным для других.

Что происходит с использованием ТИКА в открытых обходах, что анализатор Тика получает все, что болт JSOUPParser не обработал: Молнии, изображения, видео и т.д.... как правило, эти URL-адрес, как правило, очень тяжело и медленно обрабатывать и быстро входящие кортежи не резервное копирование во внутренней очереди, пока не взорвется памяти.

Я только что совершил Набор MimeType белый список для Тика Parser # 712 который позволяет определить набор регулярных выражений, которые будут опробованы на тип содержимого для документа. если есть совпадение, документ обрабатывается, если нет, то кортеж отправляется в поток STATUS как ошибка.

Вы можете настроить белый список, как так:

parser.mimetype.whitelist:
 - application/.+word.*
 - application/.+excel.*
 - application/.+powerpoint.*
 - application/.*pdf.*

Это должно сделать топологию намного более быстрым и стабильным. Дайте мне знать, как она идет.