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