[ 
https://issues.apache.org/jira/browse/STORM-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999303#comment-14999303
 ] 

ASF GitHub Bot commented on STORM-1190:
---------------------------------------

Github user danielschonfeld commented on the pull request:

    https://github.com/apache/storm/pull/870#issuecomment-155558444
  
    @revans2 i think we might have had different understandings about what I 
was suggesting or maybe I just didn't understand the problem correctly.
    
    I thought the objective was to reduce the number of threads in total.  In 
doing so, having only one single thread that goes to sleep constantly why 
submitting the required flush to a global ExecutorService that will take care 
of the **all** the flushing needed by all bolts/spouts on a single worker JVM.
    
    In your implementation we still have a thread per DisruptorQueue doing 
pretty much the same thing as before, but instead of doing the flushes on the 
same thread, we split the tasks into a multi-threaded approach and try to do it 
faster that way.  That's not what I had intended with the above example.
    
    I'd love to hear your thoughts on this.


> System load spikes in recent snapshot
> -------------------------------------
>
>                 Key: STORM-1190
>                 URL: https://issues.apache.org/jira/browse/STORM-1190
>             Project: Apache Storm
>          Issue Type: Bug
>          Components: storm-core
>    Affects Versions: 0.11.0
>         Environment: 10x (CoreOS stable (766.4.0) / k8s 1.0.1 / docker 
> running on Azure VMs)
>            Reporter: Michael Schonfeld
>            Priority: Critical
>         Attachments: Screenshot 2015-11-08 22.17.57.png, Screenshot 
> 2015-11-08 22.18.06.png
>
>
> We've been running Storm's snapshots on our production cluster for a little 
> while now (that back pressure support really helped us), and we've noticed a 
> sudden spike in system load when going from 
> commit@ba1250993d10ffc523c9f5464371fbeb406d216f to the current latest 
> commit@c12e28c829fcfabc0a3a775fb9714968b7e3e349. Both versions were running 
> the exact same topologies, and there was no significant change in workload. 
> Not exactly sure how to even begin to debug this, so we ended up just rolling 
> back. Thoughts?
> Stats screenshots attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to