yanli

@lw-lin 谢谢你的解答 try-catch的代码还没有试过，测试了下MEMORY_AND_DISK_2，性能比MEMORY_AND_DISK差很多，目前测试业务下数据处理性能差不多是这样的关系 ：4 \* MEMORY_AND_DISK_2 = MEMORY_AND_DISK 。 Executor被kill的原因，是Active Job队列里面任务开始积压，处理时延增加。Job的提交周期是1秒，由于CPU平均使用率到95%左右，Receiver接收速率不变，每个Job处理时延增加到了5到10s，目前Job的提交Interval能动态指定吗？

@lw-lin - receiver : 2 - Executor : 2 - Vcore: 每个机器64个VCore，全分配给Executor 每个Block差不多6M左右，batch duration: 1s, 每个batch处理的events没有注意，应该是12000多个吧。 **测试了下try-catch，可以解决Executor被kill的情况**:+1:

@lw-lin 关于这个问题我跟踪了下Driver和Executor端的debug日志，日志中有些问题暂时不明白，想请教下，下面信息是从Driver端Akka消息的角度整理的，完成的日志太大，不方便post > Driver：node4 > Executors：node2，node3 1. node2的上报数据更新请求：UpdateBlockInfo(input-0-1460509204597)，处理成功 2. node2发送AddBlock请求，处理成功，数据块存储在node2，块大小5.6MB 3. sparkDriver端产生GetLocations消息，处理成功 4. _**sparkDriver端发出RemoveBlock消息，此时node2上的BlockManager执行了remove操作**_ 5. node2发送UpdateBlockInfo消息，此时块的存储级别变为None 6. sparkDriver端产生GetLocations，产生java.lang.Exception: Could not compute split, block input-0-1460509204597 not found （4次）**（7~11的日志发生了两分钟后）** 7. node3上报更新请求：UpdateBlockInfo，存储块input-0-1460509204597到node3,块大小4.8MB 8....

@lw-lin spark 1.5.2 StorageLevel : `MEMORY_AND_DISK` 没有window操作

@keepsimplefocus 没有

@proflin 已发

@keepsimplefocus 谢谢，源码中加了日志，在跟踪

@lw-lin 请问Spark Streaming为了避免重复计算，对DStream做一次cache以后，为什么性能下降很厉害？在使用cache操作的时候有什么地方需要注意吗？

I had the same problem. - Compile using community documentation. - I decompiled the rss-client-spark3-0.6.0-shaded.jar package, and found no `org.apache.uniffle.com.google.protobuf.GeneratedMessageV3.isStringEmpty(Ljava/lang/Object;)Z` method.

> > I had the same problem. > > > > * Compile using community documentation. > > * I decompiled the rss-client-spark3-0.6.0-shaded.jar package, and found no `org.apache.uniffle.com.google.protobuf.GeneratedMessageV3.isStringEmpty(Ljava/lang/Object;)Z` method. >...