我们为这个问题奋斗了很长时间。简言之,我们的风暴拓扑在一段时间后停止以随机方式从喷口发出消息。我们有一个自动化的脚本,在主数据刷新活动完成后,它会在每天6:00 utc重新部署拓扑。
在过去的两周内,我们的拓扑在utc晚些时候(22:00到02:00之间)停止发送消息3次。只有当我们重新启动它时,它才会联机,大约是协调世界时06:00。
我已经搜索了很多答案和博客,但找不到这里发生了什么。我们有一个未锚定的拓扑结构,这是我们3-4年前做出的选择。我们从0.9.2开始,现在是1.1.0。
我查过所有的日志,我百分之百肯定 nextTuple()
没有调用控制器的方法,并且系统中没有可能导致此问题的异常发生。我也检查了所有我们积累的日志,甚至没有一个错误或警告日志解释突然停止。信息日志也没那么有用。在工作者日志、主管日志或nimbus日志中,没有与此问题相关的内容。
这就是我们的spout类的外观:controller.java
public class Controller implements IRichSpout {
SpoutOutputCollector _collector;
Calendar LAST_RUN = null;
List<ControllerMessage> msgList;
/**
* It is to open the spout
*/
public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) {
_collector = collector;
msgList= new ArrayList<ControllerMessage>();
MongoIndexingHandler mongoIndexingHandler = new MongoIndexingHandler();
mongoIndexingHandler.createMongoIndexes();
}
/**
* It executes the next tuple
*/
@Override
public void nextTuple() {
Map<String, Object> logMap = new HashMap<>();
logMap.put("BEGIN", new Date());
try {
TriggerHandler thandler = new TriggerHandler();
if (msgList.size() == 0) {
List<ControllerMessage> mList = thandler.getControllerMessage(new Date());
msgList = mList;
}
if (msgList.size() > 0) {
ControllerMessage message = msgList.get(0);
if(thandler.fire(message.getFireTime())) {
Util.log(message, "CONTROLLER_LOGS", message.getTime(), new Date());
msgList.remove(0);
_collector.emit(new Values(message));
}
}
else{
Utils.sleep(1000);
}
} catch (Exception e) {
_collector.reportError(e);
Util.exLog(e, "EXECUTOR_ERROR", new Date(), "nextTuple()",Controller.class);
}
}
/**
* It acknowledges the messages
*/
@Override
public void ack(Object id) {
}
/**
* It tells failed messages
*/
@Override
public void fail(Object id) {
}
/**
* It declares the message name
*/
@Override
public void declareOutputFields(OutputFieldsDeclarer declarer) {
declarer.declare(new Fields("SPOUT_MESSAGE"));
}
@Override
public void activate() {
}
@Override
public void close() {
}
@Override
public void deactivate() {
}
@Override
public Map<String, Object> getComponentConfiguration() {
return null;
}
}
这是拓扑类:diagnostictopology.java
public class DiagnosticTopology {
public static void main(String[] args) throws Exception {
int gSize = (null != args && args.length > 0) ? Integer.parseInt(args[0]) : 2;
int sSize = (null != args && args.length > 1) ? Integer.parseInt(args[1]) : 128;
int sMSize = (null != args && args.length > 2) ? Integer.parseInt(args[2]) : 16;
int aGSize = (null != args && args.length > 3) ? Integer.parseInt(args[3]) : 16;
int rSize = (null != args && args.length > 4) ? Integer.parseInt(args[4]) : 64;
int rMSize = (null != args && args.length > 5) ? Integer.parseInt(args[5]) : 16;
int dMSize = (null != args && args.length > 6) ? Integer.parseInt(args[6]) : 8;
int wSize = (null != args && args.length > 7) ? Integer.parseInt(args[7]) : 16;
String topologyName = (null != args && args.length > 8) ? args[8] : "DIAGNOSTIC";
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout("controller", new Controller(), 1);
builder.setBolt("generator", new GeneratorBolt(), gSize).shuffleGrouping("controller");
builder.setBolt("scraping", new ScrapingBolt(), sSize).shuffleGrouping("generator");
builder.setBolt("smongo", new MongoBolt(), sMSize).shuffleGrouping("scraping");
builder.setBolt("aggregation", new AggregationBolt(), aGSize).shuffleGrouping("scraping");
builder.setBolt("rule", new RuleBolt(), rSize).shuffleGrouping("smongo");
builder.setBolt("rmongo", new RMongoBolt(), rMSize).shuffleGrouping("rule");
builder.setBolt("dstatus", new DeviceStatusBolt(), dMSize).shuffleGrouping("rule");
builder.setSpout("trigger", new TriggerSpout(), 1);
builder.setBolt("job", new JobTriggerBolt(), 4).shuffleGrouping("trigger");
Config conf = new Config();
conf.setDebug(false);
conf.setNumWorkers(wSize);
StormSubmitter.submitTopologyWithProgressBar(topologyName, conf, builder.createTopology());
}
}
我们为生产和测试环境准备了相当好的服务器(xeon、8核、32 gb和闪存驱动器),并且没有外部因素会导致此问题,因为异常处理在代码中无处不在。
当这件事发生的时候,似乎一切都突然停止了,也没有发生原因的痕迹。
非常感谢您的帮助!
2条答案
按热度按时间zvms9eto1#
我不知道是什么原因导致您的问题,但我建议您首先检查升级到最新的storm版本是否可以解决此问题。我知道至少有两个问题与工人线程死亡和不再回来https://issues.apache.org/jira/browse/storm-1750httpshttp://issues.apache.org/jira/browse/storm-2194。1750在1.1.0中固定,但2194直到1.1.1才固定。
如果升级不能解决问题,您可以通过执行以下操作来调试它。
下一次当你的拓扑挂起时,打开StormUI找到你的喷口。它将显示运行喷口的执行者列表,以及负责运行喷口的工人。选择一个喷口执行器没有排放任何东西的工人。在运行这个worker的机器上打开一个shell,并找到worker jvm的进程id
jps -m
.示例输出显示了本地计算机(pid 7592)上端口为6701的工作jvm:
7592工人测试-2-1520361882 d24dc55d-76c7-4cc6-93fa-2663fcdcb1ba-10.0.75.1 6701 f7b6f8e4-6c87-47ca-a7b7-655009b6c62a
通过执行以下操作触发线程转储
kill -3 <pid>
,或使用jstack <pid>
如果你愿意的话。在线程转储中,您应该能够找到挂起的执行器线程。例如,当我对一个带有一个名为“word”的喷口的拓扑进行线程转储时,其中一个喷口执行器的编号是13,我看到了
edit:堆栈溢出不允许我发布堆栈跟踪,因为查找未格式化代码的启发式方法不好。我花了和写原始答案一样长的时间来发布堆栈跟踪,所以我不想再继续尝试了。这是应该在这里的痕迹https://pastebin.com/2sz5kkq1
这显示了13号执行官目前在做什么。在这种情况下,它在调用nexttuple时处于休眠状态。
如果你能发现你的执行者在做什么,你应该有更好的设备来解决这个问题,或者向storm报告一个bug。
42fyovps2#
我们在应用程序中观察到了这一点,当时cpu非常繁忙,所有其他线程都在等待轮到它们。当我们试图使用jvisualvm检查资源使用情况来找到根本原因时,我们发现某些螺栓中的某些函数会导致大量开销和cpu时间。请通过检查。如果nexttuple()方法的cpu关键路径中有阻塞的线程,或者您正在从上游接收相同的数据,则可以使用任何分析工具。