我有一个完全专用于基于 Storm-Crawler 的爬虫的节点。我拥有 20 个双核 CPU、130 Gb RAM 和 10Gb/s 以太网连接。
我将拓扑简化为：CollapsingSpout -> URLPartitionerBolt -> FetcherBolt。spout 正在从 Elasticsearch 索引（大约 50 M 记录）中读取数据。Elasticsearch 配置了 30 GB RAM 和 2 个分片。
我使用一个具有大约 50 GB RAM 专用于 JVM 的工作人员。使用不同的设置（线程总数，每个队列的线程数，最大挂起的 spout，一些与 Elasticsearch 相关的，例如桶数和桶大小）我可以达到 100 MB/s 的整体获取速度。但是，查看 ganglia 报告，它仅对应于我可用带宽的 10%。请注意，CPU 使用率约为 20%，RAM 不是问题。
我正在寻找一些关于什么可能是我的瓶颈的提示，以及关于如何调整/调整我的爬虫以充分利用我可用的资源的建议。
提前致谢。
艾蒂安
您可以使用 Kibana 或 Grafana 来可视化 StormCrawler 生成的指标，请参阅教程。这将使您对性能有一些了解。此外，Storm UI 会告诉您组件级别的瓶颈。
您可以为状态索引使用超过 2 个分片，并拥有相应数量的 spout 实例。这将增加并行度。
您是否关注网页的外链或索引的大小是否保持不变？50M 的 url 不是很多，所以我不认为 ES 会超级忙。
您是否尝试过使用 AggregationSpout 代替？CollapsingSpout 是相当新的 + 使用桶大小为 1 可能会更好，因为我认为它会为每个桶发出单独的查询。
如果不查看您的拓扑，很难准确判断问题出在哪里。尝试使用上述方法找到任何明显的罪魁祸首。
朱利安，非常感谢您的反馈。我将我的 spout 更改为 AggregationSpout 并将您的仪表板导入 Kibana。
我使用 aggregationSpout->partitioner->dummyIndexer->statusUpdater 进行了测试，以确认我的 spout 能够根据需要发出并且没问题（大约 0.3 M 元组/分钟，这基本上是我整个目标的两倍拓扑 10 M 元组/小时）。
不过，我仍然对抓取的性能不满意。从活动线程的数量、队列数量和队列大小的高度波动的意义上说，它非常不稳定。而且我有一种感觉，当我增加太多线程的总数（几千个）时，抓取器会以某种方式失去控制。
根据您的经验，每个 fetcher 实例允许的最大线程数是多少？而且由于每个工人只需要一个提取器实例，您是否发现启动多个工人以拥有并发提取器有任何问题？